BCP on throttling outbound mail

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

BCP on throttling outbound mail

Charles Sprickman
Hello,

Sorry for the broad question, but is there any sort of best common practice these days regarding limiting outbound email?  We recently had a customer's account compromised (not sure if it was brute-forced or keylogged) and then the perp proceeded to use their credentials to smtp-auth themselves a huge load of viagra spam.

I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.  I assume this is not an uncommon scenario, but pointers from those with more Postfix experience would be quite welcome.

I do have amavis available for outbound virus scanning, and could conceivably have it do the same with spam scanning but that feels not quite right (and probably fairly resource intensive if someone was trying to cram tens of thousands of messages through the system).

Thanks,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Stan Hoeppner
On 7/23/2012 4:16 PM, CSS wrote:

> I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.

See:
http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit

You would apply this to your submission service, eg:

587      inet  n       -       n       -       -       smtpd
        -o smtpd_enforce_tls=yes
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_client_connection_rate_limit=1

This limits spammers and legit users to 1 msg/min, 60 msgs per hour.
Postfix is not psychic.

This may be a problem for roaming users who send batches of mails when
they get a connection--10 msgs takes 10 minutes.  Thus, as with
anything, some analysis and [re]tuning will be required.  If you trust
some users to never have their acct compromised, you can always create
multiple submission services on different ports and have different
limits for different sets of users, or even no limits for some.

Not a perfect solution, but better than what you have now.

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Charles Sprickman

On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote:

> On 7/23/2012 4:16 PM, CSS wrote:
>
>> I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.
>
> See:
> http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit
>
> You would apply this to your submission service, eg:
>
> 587      inet  n       -       n       -       -       smtpd
> -o smtpd_enforce_tls=yes
> -o smtpd_sasl_auth_enable=yes
> -o smtpd_client_connection_rate_limit=1
>
> This limits spammers and legit users to 1 msg/min, 60 msgs per hour.
> Postfix is not psychic.
>
> This may be a problem for roaming users who send batches of mails when
> they get a connection--10 msgs takes 10 minutes.  Thus, as with
> anything, some analysis and [re]tuning will be required.  If you trust
> some users to never have their acct compromised, you can always create
> multiple submission services on different ports and have different
> limits for different sets of users, or even no limits for some.
>
> Not a perfect solution, but better than what you have now.

I'm looking at "policyd2/cluebringer" as well, but it's non-intuitive to say the least.  Install is easy, hooking in to postfix is easy, but there's a huge lack of howto docs on configuring the actual policies for specific use cases.  The quota module looks great, but getting data into the config to delineate internal vs. external domains (and what about a sasl-authenticated user sending from another domain?) is quite challenging.  If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers.

Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting?

It seems like the internet as whole would certainly benefit from a dead-simple policy daemon that could thwart the attempts of spammers using hijacked credentials to spew their junk.

Thanks,

Charles

>
> --
> Stan
>

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Stan Hoeppner
On 7/24/2012 12:44 AM, CSS wrote:

>
> On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote:
>
>> On 7/23/2012 4:16 PM, CSS wrote:
>>
>>> I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.
>>
>> See:
>> http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit
>>
>> You would apply this to your submission service, eg:
>>
>> 587      inet  n       -       n       -       -       smtpd
>> -o smtpd_enforce_tls=yes
>> -o smtpd_sasl_auth_enable=yes
>> -o smtpd_client_connection_rate_limit=1
>>
>> This limits spammers and legit users to 1 msg/min, 60 msgs per hour.
>> Postfix is not psychic.
>>
>> This may be a problem for roaming users who send batches of mails when
>> they get a connection--10 msgs takes 10 minutes.  Thus, as with
>> anything, some analysis and [re]tuning will be required.  If you trust
>> some users to never have their acct compromised, you can always create
>> multiple submission services on different ports and have different
>> limits for different sets of users, or even no limits for some.
>>
>> Not a perfect solution, but better than what you have now.

>  If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers.

Apparently you didn't read the docs I provided.
http://www.postfix.org/postconf.5.html#anvil_rate_time_unit

The time unit over which client connection rates and other rates are
calculated.

Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
The default time unit is s (seconds)

> Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting?

Probably.  But I think you summarily discounted the inbuilt Postfix
equivalent too quickly, without even looking at it.  You can having it
running in less than 60 seconds.

> It seems like the internet as whole would certainly benefit from a dead-simple policy daemon that could thwart the attempts of spammers using hijacked credentials to spew their junk.

You'd think humans beings would be smart enough to follow directions and
use strong passwords, AV software, etc, and not fall for phishing scams.
 Your adversary in this war isn't the spammers, it's not the technology,
but your users.

You should not be expending any more time/effort on the tech piece of
the solution beyond finding the most basic rate limiting tool and
enabling it to prevent spewage, right now.  This is the smallest battle
in this war.

The big battles are user education (AV software on their machines, safe
surfing habits, anti-phish education, etc), and wholesale forcing all
users to change to *enforced* strong passwords.

The user related stuff wins this war.  The tech portion merely decreases
the amount of damage per clueless user battle.

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Charles Sprickman

On Jul 24, 2012, at 2:37 AM, Stan Hoeppner wrote:

> On 7/24/2012 12:44 AM, CSS wrote:
>>
>> On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote:
>>
>>> On 7/23/2012 4:16 PM, CSS wrote:
>>>
>>>> I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.
>>>
>>> See:
>>> http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit
>>>
>>> You would apply this to your submission service, eg:
>>>
>>> 587      inet  n       -       n       -       -       smtpd
>>> -o smtpd_enforce_tls=yes
>>> -o smtpd_sasl_auth_enable=yes
>>> -o smtpd_client_connection_rate_limit=1
>>>
>>> This limits spammers and legit users to 1 msg/min, 60 msgs per hour.
>>> Postfix is not psychic.
>>>
>>> This may be a problem for roaming users who send batches of mails when
>>> they get a connection--10 msgs takes 10 minutes.  Thus, as with
>>> anything, some analysis and [re]tuning will be required.  If you trust
>>> some users to never have their acct compromised, you can always create
>>> multiple submission services on different ports and have different
>>> limits for different sets of users, or even no limits for some.
>>>
>>> Not a perfect solution, but better than what you have now.
>
>> If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers.
>
> Apparently you didn't read the docs I provided.
> http://www.postfix.org/postconf.5.html#anvil_rate_time_unit

I actually have some rate-limiting already, but obviously not enough.

>
> The time unit over which client connection rates and other rates are
> calculated.
>
> Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
> The default time unit is s (seconds)

Perhaps I'm misunderstanding this, but I was under the impression that the anvil limits were all enforced on a per-connection or per-IP limit.  I'm really after something that can track a particular sasl-authenticated user and punish them (and not other users).  I'll re-read what I can find on anvil again, the recommendations against its use in this situation may have been dated.

>
>> Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting?
>
> Probably.  But I think you summarily discounted the inbuilt Postfix
> equivalent too quickly, without even looking at it.  You can having it
> running in less than 60 seconds.

Which I may just do in hopes it can provide a base level of protection.

>
>> It seems like the internet as whole would certainly benefit from a dead-simple policy daemon that could thwart the attempts of spammers using hijacked credentials to spew their junk.
>
> You'd think humans beings would be smart enough to follow directions and
> use strong passwords, AV software, etc, and not fall for phishing scams.
> Your adversary in this war isn't the spammers, it's not the technology,
> but your users.

I've worked with end users since 1995.  They aren't changing.  In fact, the facebook-ization of the internet is bringing us right back to the good old AOL days of walled gardens.  Users are getting less, not more savvy.

>
> You should not be expending any more time/effort on the tech piece of
> the solution beyond finding the most basic rate limiting tool and
> enabling it to prevent spewage, right now.  This is the smallest battle
> in this war.

Funny, as I was speaking to my partner about this issue and he was wondering why all the spam wars are being fought on the recipient end - so many cpu cycles and hardware to filter the 20% or so of good mail from the bad.  He could not grasp why the source of the spam could not be legislated away.

> The big battles are user education (AV software on their machines, safe
> surfing habits, anti-phish education, etc), and wholesale forcing all
> users to change to *enforced* strong passwords.

I had suspected a guessable password, and I was wrong.  This customer routinely calls in with various issues and the tech that works with them has the password so he can login to webmail as the customer and verify whatever oddity they see.  It was not the best, but it was random, mixed-case, mixed numbers and letters.  Was it a *unique* password?  Probably not...

> The user related stuff wins this war.  The tech portion merely decreases
> the amount of damage per clueless user battle.

The war will be lost.  TimeWarner, Comcast, Verizon and everyone else is not going to either lose customers by cutting off the ever-infected clueless or spend time (money) educating them...

Charles


> --
> Stan
>

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Stan Hoeppner
On 7/24/2012 2:08 AM, CSS wrote:

> Perhaps I'm misunderstanding this, but I was under the impression that the anvil limits were all enforced on a per-connection or per-IP limit.  I'm really after something that can track a particular sasl-authenticated user and punish them (and not other users).  I'll re-read what I can find on anvil again, the recommendations against its use in this situation may have been dated.

It's per client IP.  But Postfix logs client IP with or in proximity to
the SASL username, so it shouldn't be hard to x-reference the user who
starts tripping anvil.  But you'll want a log monitor that emails you
when anvil trips, so you can disable compromised accounts, not allowing
them to continue leaking, hitting traps, getting you blacklisted, etc.

>>> Are there any other specific policy daemons I've missed that deal explicitly with rate-limiting?
>>
>> Probably.  But I think you summarily discounted the inbuilt Postfix
>> equivalent too quickly, without even looking at it.  You can having it
>> running in less than 60 seconds.
>
> Which I may just do in hopes it can provide a base level of protection.

-o smtpd_client_connection_rate_limit=10

may be a good starting point.  Road warriors can thus blast 10 saved
msgs at full throttle, but msg 11 will have to wait until 60s after the
first msg.  After the 2nd/3rd email notification from your anvil
watcher, you'll can be certain you have a compromised account (or a
misbehaving user).  If you/staff are able to react in 5 minutes, only 50
spams have escaped.  Obviously full automation of account disabling
along with staff notification would be preferable.  Scripting all this
shouldn't be too difficult.

> I've worked with end users since 1995.  

You sir are a saint.

> They aren't changing.  In fact, the facebook-ization of the internet is bringing us right back to the good old AOL days of walled gardens.  Users are getting less, not more savvy.

Percentage wise I'd say savvy-ness is the same.  Problem is we have
~100M more internet users (US anyway) than in '95.  So yes, total number
of dumb users has increased many fold, no argument there.

> Funny, as I was speaking to my partner about this issue and he was wondering why all the spam wars are being fought on the recipient end - so many cpu cycles and hardware to filter the 20% or so of good mail from the bad.  He could not grasp why the source of the spam could not be legislated away.

Heheh.  That conversation can't have been as brief as you elude. ;)

> I had suspected a guessable password, and I was wrong.  This customer routinely calls in with various issues and the tech that works with them has the password so he can login to webmail as the customer and verify whatever oddity they see.  It was not the best, but it was random, mixed-case, mixed numbers and letters.  Was it a *unique* password?  Probably not...

So if it wasn't guessed, how was it obtained?  This user sounds like
phish target, all the hand holding.

>> The user related stuff wins this war.  The tech portion merely decreases
>> the amount of damage per clueless user battle.
>
> The war will be lost.  

That's the spirit!  I won't predict the end game, but we can all agree
the war against spam will last a long time.  Also depends on the
definition of 'win'.  If we can get down to 1 spam in the inbox per week
per worldwide "average" user, I'd call the war 'won'.  One per day would
be 'winning'.

> TimeWarner, Comcast, Verizon and everyone else is not going to either lose customers by cutting off the ever-infected clueless or spend time (money) educating them...

They lose thousands of customers/day to one another just over pricing
specials and promos.  They wouldn't care one bit if they shed a few
thousand problem users.  They're likely losing profit on them anyway due
to support calls and technician visits to reset modems and bs like that.
 Likely less phone costs now that most farm level 1 to India.

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Len Conrad
In reply to this post by Charles Sprickman
At 04:16 PM 7/23/2012, you wrote:

>Hello,
>
>Sorry for the broad question, but is there any sort of best common practice these days regarding limiting outbound email?  We recently had a customer's account compromised (not sure if it was brute-forced or keylogged) and then the perp proceeded to use their credentials to smtp-auth themselves a huge load of viagra spam.
>
>I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.  I assume this is not an uncommon scenario, but pointers from those with more Postfix experience would be quite welcome.
>
>I do have amavis available for outbound virus scanning, and could conceivably have it do the same with spam scanning but that feels not quite right (and probably fairly resource intensive if someone was trying to cram tens of thousands of messages through the system).
>
>Thanks,
>
>Charles

I've been using postfwd.org for rate-limiting outbound senders, and inbound senders and IPs, plus lots of other inbound filtering, for a 2+ years.  It killed our horrible problem of cracked passwords.

Len







Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Wietse Venema
Len Conrad:
> I've been using postfwd.org for rate-limiting outbound senders,
> and inbound senders and IPs, plus lots of other inbound filtering,
> for a 2+ years.  It killed our horrible problem of cracked passwords.

I think that dedicated tools such as postfwd and the like are the
way to go. This is better (for users and developers) than trying
to provide all solutions within Postfix itself.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Charles Sprickman
In reply to this post by Len Conrad
On Jul 24, 2012, at 6:23 AM, Len Conrad wrote:

> At 04:16 PM 7/23/2012, you wrote:
>> Hello,
>>
>> Sorry for the broad question, but is there any sort of best common practice these days regarding limiting outbound email?  We recently had a customer's account compromised (not sure if it was brute-forced or keylogged) and then the perp proceeded to use their credentials to smtp-auth themselves a huge load of vxxxxxa spam.
>>
>> I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.  I assume this is not an uncommon scenario, but pointers from those with more Postfix experience would be quite welcome.
>>
>> I do have amavis available for outbound virus scanning, and could conceivably have it do the same with spam scanning but that feels not quite right (and probably fairly resource intensive if someone was trying to cram tens of thousands of messages through the system).
>>
>> Thanks,
>>
>> Charles
>
> I've been using postfwd.org for rate-limiting outbound senders, and inbound senders and IPs, plus lots of other inbound filtering, for a 2+ years.  It killed our horrible problem of cracked passwords.

If you could share some of the basics of that config, I'd love to see them.  I looked at that briefly before slogging through policyd/cluebringer, and a (very quick) read of their intro page didn't make it obvious that you could track per-user message counts.

Does anyone use the old non-perl policyd1?  That looked like an easy setup, but it's quite old.

For anyone interested, a very basic per-user (more specifically, per authenticated user, which is the only kind of user I've got outside of web apps submitting w/php) setup ended up being fairly easy to implement.  The config is all sql-based, I'd be more than happy to share a dump of the config I ended up with.  I have some doubts about how well it scales, and I've also added another single point of failure to all inbound and outbound email, but it does what it says it does.

The policy I setup basically matches all sasl-authenticated users and puts them in a queue that limits them to 100 messages per hour.  That's my starting point, I'll probably adjust it at some point.  For web applications, I'm going to install ssmtp and configure that to send with a dedicated username which will have its own limits.

Thanks,

Charles

> Len
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

mouss-4
In reply to this post by Stan Hoeppner
Le 24/07/2012 08:37, Stan Hoeppner a écrit :

> On 7/24/2012 12:44 AM, CSS wrote:
>>
>> On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote:
>>
>>> On 7/23/2012 4:16 PM, CSS wrote:
>>>
>>>> I'd like to take some measures to limit what an authenticated sender can do but not limit legitimate use.
>>>
>>> See:
>>> http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit
>>>
>>> You would apply this to your submission service, eg:
>>>
>>> 587      inet  n       -       n       -       -       smtpd
>>> -o smtpd_enforce_tls=yes
>>> -o smtpd_sasl_auth_enable=yes
>>> -o smtpd_client_connection_rate_limit=1
>>>
>>> This limits spammers and legit users to 1 msg/min, 60 msgs per hour.
>>> Postfix is not psychic.
>>>
>>> This may be a problem for roaming users who send batches of mails when
>>> they get a connection--10 msgs takes 10 minutes.  Thus, as with
>>> anything, some analysis and [re]tuning will be required.  If you trust
>>> some users to never have their acct compromised, you can always create
>>> multiple submission services on different ports and have different
>>> limits for different sets of users, or even no limits for some.
>>>
>>> Not a perfect solution, but better than what you have now.
>
>>  If I can cobble this thing together, the quota module offers things like messages per day or per hour, which is a fairly reasonable way to restrict customers.
>
> Apparently you didn't read the docs I provided.
> http://www.postfix.org/postconf.5.html#anvil_rate_time_unit
>

anvil is not an anti-spam solution. it's measure against "clients gone
crazy".

fighting outbound spam is a serious challenge.

> [skip]
> You'd think humans beings would be smart enough to follow directions and
> use strong passwords, AV software, etc, and not fall for phishing scams.
>  Your adversary in this war isn't the spammers, it's not the technology,
> but your users.

oh come on! the "users" excuse is wa too old. if your software accepts
weak passwords, then the problem is with the software, not the user. AV?
oh no, I don't want any on my unix boxen. phising? well, it's far from
being a simple thing.

when OS, pki & browser vendors will ignore their business for the
"happiness of the universe", things might get better in an Alice
wonderfull world. do you really believe it?


>
> You should not be expending any more time/effort on the tech piece of
> the solution beyond finding the most basic rate limiting tool and
> enabling it to prevent spewage, right now.  This is the smallest battle
> in this war.
>
> The big battles are user education (AV software on their machines, safe
> surfing habits, anti-phish education, etc), and wholesale forcing all
> users to change to *enforced* strong passwords.

I disagree. those who put the responsibility of their failure on others
(call em users or whataver) should get another job.

>
> The user related stuff wins this war.  The tech portion merely decreases
> the amount of damage per clueless user battle.
>

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Ansgar Wiechers
On 2012-07-25 mouss wrote:
> Le 24/07/2012 08:37, Stan Hoeppner a écrit :
>> You'd think humans beings would be smart enough to follow directions
>> and use strong passwords, AV software, etc, and not fall for phishing
>> scams. Your adversary in this war isn't the spammers, it's not the
>> technology, but your users.
>
> oh come on! the "users" excuse is wa too old. if your software accepts
> weak passwords, then the problem is with the software, not the user.

I'd have to disagree on this one. How do you measure strength or
weakness of a password?

Length? Is "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" strong?

Complexity? Is "Passw0rd" strong?

A combination of the above? Is "JosephAverage4/1/1999" strong?

Frequent password changes? Is "simplepassword##" strong? (## being a
sequential number)

How do you effectively protect your infrastructure against users or
(worse) customers writing their passwords on PostIts and leaving them
around? How do you effectively protect your infrastructure against
customers getting their own systems compromised?

If you happen to have a solution for this problem, I'm honestly
interested in learning about it, because I don't see any.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky
Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Mark Blackman-4

On 25 Jul 2012, at 08:20, Ansgar Wiechers wrote:

> On 2012-07-25 mouss wrote:
>> Le 24/07/2012 08:37, Stan Hoeppner a écrit :
>>> You'd think humans beings would be smart enough to follow directions
>>> and use strong passwords, AV software, etc, and not fall for phishing
>>> scams. Your adversary in this war isn't the spammers, it's not the
>>> technology, but your users.
>>
>> oh come on! the "users" excuse is wa too old. if your software accepts
>> weak passwords, then the problem is with the software, not the user.
>
> I'd have to disagree on this one. How do you measure strength or
> weakness of a password?
>
> Length? Is "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" strong?
>
> Complexity? Is "Passw0rd" strong?
>
> A combination of the above? Is "JosephAverage4/1/1999" strong?
>
> Frequent password changes? Is "simplepassword##" strong? (## being a
> sequential number)
>
> How do you effectively protect your infrastructure against users or
> (worse) customers writing their passwords on PostIts and leaving them
> around? How do you effectively protect your infrastructure against
> customers getting their own systems compromised?
>
> If you happen to have a solution for this problem, I'm honestly
> interested in learning about it, because I don't see any.

Isn't the conventional wisdom that a long password consisting of 3 or 4
common but longer words is sufficient and memorable, along the lines
of the famous XKCD panel?

Obviously there's more to it than that, but I didn't think there was
much disagreement about the ideal form of a memorable and strong password.
It's a given that your attacker will have an idea what form of password
to test for, if not the actual password.

Mark


Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Ansgar Wiechers
Mark,

On 2012-07-25 Mark Blackman wrote:

> On 25 Jul 2012, at 08:20, Ansgar Wiechers wrote:
>> On 2012-07-25 mouss wrote:
>>> oh come on! the "users" excuse is wa too old. if your software accepts
>>> weak passwords, then the problem is with the software, not the user.
>>
>> I'd have to disagree on this one. How do you measure strength or
>> weakness of a password?
>>
>> Length? Is "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" strong?
>>
>> Complexity? Is "Passw0rd" strong?
>>
>> A combination of the above? Is "JosephAverage4/1/1999" strong?
>>
>> Frequent password changes? Is "simplepassword##" strong? (## being a
>> sequential number)
>>
>> How do you effectively protect your infrastructure against users or
>> (worse) customers writing their passwords on PostIts and leaving them
>> around? How do you effectively protect your infrastructure against
>> customers getting their own systems compromised?
>>
>> If you happen to have a solution for this problem, I'm honestly
>> interested in learning about it, because I don't see any.
>
> Isn't the conventional wisdom that a long password consisting of 3 or 4
> common but longer words is sufficient and memorable, along the lines
> of the famous XKCD panel?

Please re-read what I wrote, particularly the second half of it. Is
"Joseph Zebediah Average 4/1/1999" really a strong password? If not: how
do you prevent users/customers from using a password like that? And how
do you prevent a customer's system from being compromised with, say, a
keylogger?

> Obviously there's more to it than that, but I didn't think there was
> much disagreement about the ideal form of a memorable and strong
> password. It's a given that your attacker will have an idea what form
> of password to test for, if not the actual password.

Indeed there isn't much disagreement on what forms a strong password (in
principle). I do fail to see how this could be enforced on a technical
level, though.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky
Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Mark Blackman-4
On 25 Jul 2012, at 10:09, Ansgar Wiechers wrote:

> Mark,
>
>
> Please re-read what I wrote, particularly the second half of it. Is
> "Joseph Zebediah Average 4/1/1999" really a strong password?

It is a strong password, unless you believe attackers would regard that
format as a promising format to exploit. I think that's unlikely to
be a promising format to exploit at the moment.

> If not: how
> do you prevent users/customers from using a password like that?

Well, if you really believe that format is likely, you test for it.

> And how
> do you prevent a customer's system from being compromised with, say, a
> keylogger?

Keyloggers are a completely separate question from passwords and operate
on a different level.

>
>> Obviously there's more to it than that, but I didn't think there was
>> much disagreement about the ideal form of a memorable and strong
>> password. It's a given that your attacker will have an idea what form
>> of password to test for, if not the actual password.
>
> Indeed there isn't much disagreement on what forms a strong password (in
> principle). I do fail to see how this could be enforced on a technical
> level, though.

You can readily enforce minimum length of say 12-16 characters which is a
great place to start and of course that says nothing about keyloggers
or other infiltrations.

If you're assuming that keyloggers are omnipresent, then you've already
given up on security.

Mark
Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Stan Hoeppner
In reply to this post by mouss-4
On 7/24/2012 6:24 PM, mouss wrote:

> anvil is not an anti-spam solution. it's measure against "clients gone
> crazy".

Precisely.  And that's how I advised the OP to us it:  Plug the artery
until surgery can be performed.  Surgery in this case being disabling
the account and setting a strong password.

> fighting outbound spam is a serious challenge.

Of course it is, harder for some org types and easier for others.  ISPs
have the toughest battle here, obviously.  Many/most corps and SOHOs not
so tough.

>> [skip]
>> You'd think humans beings would be smart enough to follow directions and
>> use strong passwords, AV software, etc, and not fall for phishing scams.
>>  Your adversary in this war isn't the spammers, it's not the technology,
>> but your users.
>
> oh come on! the "users" excuse is wa too old. if your software accepts
> weak passwords, then the problem is with the software, not the user. AV?
> oh no, I don't want any on my unix boxen. phising? well, it's far from
> being a simple thing.

It's not an excuse, but a fact.  I'm surprised you'd argue this mouss.
;)  Success requires a multi-pronged approach, and all of the above are
required.  over 99% of users have Windows not *nix desktops, so the AV
requirement is a given.  And even with software that enforces strong
passwords, many users fall prey to phish and give up the password.
Which is why the only way to win this hacked account spam is user
education.  Now, whether that's a pipe dream or achievable will be
debated forever.

> when OS, pki & browser vendors will ignore their business for the
> "happiness of the universe", things might get better in an Alice
> wonderfull world. do you really believe it?

As long as human beings are allowed to submit mail to their provider for
relay, and those humans control their machines doing the submitting,
it's ultimately up to those users to secure their logon information.
The ISP can't control the user PC or the user.  It can only attempt to
educate.  As myself and others have stated many times, there is no
technical solution to this side of the spam problem, as there is no
technical solution to the MX recipient side of the spam problem.  One
can only mitigate and fix, which...

Is why I recommended using anvil for the mitigation part.  It's quick,
it's integrated, it's low overhead vs a policy daemon.  But yes, it
requires some custom scripting to match up the auth user name for
account disabling.

> I disagree. those who put the responsibility of their failure on others
> (call em users or whataver) should get another job.

More accounts are compromised via phishing than brute force attacks.
Are you calling this a failure on the part of the technical staff at
$ISP?  Are you saying technical means readily exist to stop phishing?

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Stan Hoeppner
In reply to this post by Ansgar Wiechers
On 7/25/2012 4:09 AM, Ansgar Wiechers wrote:

> Indeed there isn't much disagreement on what forms a strong password (in
> principle). I do fail to see how this could be enforced on a technical
> level, though.

Use a plugin such as:
http://www.html-form-guide.com/web-form-widget/web-form-password-widget.html

and modify the code to only accept passwords that pass a set threshold.

--
Stan

Reply | Threaded
Open this post in threaded view
|

Re: BCP on throttling outbound mail

Ansgar Wiechers
In reply to this post by Mark Blackman-4
On 2012-07-25 Mark Blackman wrote:
> On 25 Jul 2012, at 10:09, Ansgar Wiechers wrote:
>> Please re-read what I wrote, particularly the second half of it. Is
>> "Joseph Zebediah Average 4/1/1999" really a strong password?
>
> It is a strong password, unless you believe attackers would regard
> that format as a promising format to exploit. I think that's unlikely
> to be a promising format to exploit at the moment.

I would regard any combination of personal name and birth date as a
pretty darn promising format to exploit at any time.

>> If not: how do you prevent users/customers from using a password like
>> that?
>
> Well, if you really believe that format is likely, you test for it.

How would you test for likely combinations of users' (or customers')
personal information? And how do you account for the reduction in key
space these checks would introduce?

>> And how do you prevent a customer's system from being compromised
>> with, say, a keylogger?
>
> Keyloggers are a completely separate question from passwords and
> operate on a different level.

I beg to differ. Keyloggers are a rather prominent means for obtaining
passwords.

>>> Obviously there's more to it than that, but I didn't think there was
>>> much disagreement about the ideal form of a memorable and strong
>>> password. It's a given that your attacker will have an idea what
>>> form of password to test for, if not the actual password.
>>
>> Indeed there isn't much disagreement on what forms a strong password
>> (in principle). I do fail to see how this could be enforced on a
>> technical level, though.
>
> You can readily enforce minimum length of say 12-16 characters which
> is a great place to start and of course that says nothing about
> keyloggers or other infiltrations.

Length is just that: a good start. It's nothing more. Particularly it's
not a silver bullet. I can easily name you passwords or phrases of 20
characters length, which would require very, VERY little effort to
break. "aaaaaaaaaaaaaaaaaaaa" being the simplest of examples.

> If you're assuming that keyloggers are omnipresent, then you've
> already given up on security.

No. That doesn't change anything about keyloggers being an apparent
threat, though. Omnipresence is not required.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky
Reply | Threaded
Open this post in threaded view
|

off-topic discussions

Jim Reid
Please take your debate about password selection policies elsewhere.  
It has nothing to do with postfix.