Limit the damage of a hacked sender acount

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Limit the damage of a hacked sender acount

Daniel L. Miller
I had a couple of accounts with too simple passwords hacked. And obviously
my mail server is entirely too efficient - I think about 50k spams got
blasted out before I caught it (because we got in the DNSBL's).

Separate from improving the password security - what can I do to limit the
damage a compromised account can cause? Without receiving user complaints
about not being able to send the latest cute kitty pictures to their whole
addressbook?

Are there per-sender limits that can/should be applied? And is there a way
I can be notified of a suspicious condition - without manually monitoring
the queue?

--
Daniel


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

Wietse Venema
Daniel Miller:

> I had a couple of accounts with too simple passwords hacked. And obviously
> my mail server is entirely too efficient - I think about 50k spams got
> blasted out before I caught it (because we got in the DNSBL's).
>
> Separate from improving the password security - what can I do to limit the
> damage a compromised account can cause? Without receiving user complaints
> about not being able to send the latest cute kitty pictures to their whole
> addressbook?
>
> Are there per-sender limits that can/should be applied? And is there a way
> I can be notified of a suspicious condition - without manually monitoring
> the queue?

Search for "postfix policy rate limit"

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

lists@lazygranch.com
In reply to this post by Daniel L. Miller
Don't offer any unencrypted email accounts. That won't insure good passwords,  but at least it will stop leaks over public wifi.

I had to dig back a bit ‎in my cranium for "driftnet". Never ran it myself, but supposedly it steals all sorts of unencrypted goodies.

  Original Message  
From: Daniel Miller
Sent: Friday, June 23, 2017 4:38 PM
To: [hidden email]
Subject: Limit the damage of a hacked sender acount

I had a couple of accounts with too simple passwords hacked. And obviously
my mail server is entirely too efficient - I think about 50k spams got
blasted out before I caught it (because we got in the DNSBL's).

Separate from improving the password security - what can I do to limit the
damage a compromised account can cause? Without receiving user complaints
about not being able to send the latest cute kitty pictures to their whole
addressbook?

Are there per-sender limits that can/should be applied? And is there a way
I can be notified of a suspicious condition - without manually monitoring
the queue?

--
Daniel


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

CSS-4
In reply to this post by Wietse Venema

> On Jun 23, 2017, at 8:11 PM, Wietse Venema <[hidden email]> wrote:
>
> Daniel Miller:
>> I had a couple of accounts with too simple passwords hacked. And obviously
>> my mail server is entirely too efficient - I think about 50k spams got
>> blasted out before I caught it (because we got in the DNSBL's).
>>
>> Separate from improving the password security - what can I do to limit the
>> damage a compromised account can cause? Without receiving user complaints
>> about not being able to send the latest cute kitty pictures to their whole
>> addressbook?
>>
>> Are there per-sender limits that can/should be applied? And is there a way
>> I can be notified of a suspicious condition - without manually monitoring
>> the queue?
>
> Search for "postfix policy rate limit”

Does anyone have pointers to a particularly “smart” rate-limiting setup?

I’ve been watching the bad guys bump into the limit, then adjust down from there, sometimes to just barely a trickle.

Charles

>
> Wietse

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

allenc
In reply to this post by Daniel L. Miller


On 24/06/17 00:37, Daniel Miller wrote:

> I had a couple of accounts with too simple passwords hacked. And
> obviously my mail server is entirely too efficient - I think about 50k
> spams got blasted out before I caught it (because we got in the DNSBL's).
>
> Separate from improving the password security - what can I do to limit
> the damage a compromised account can cause? Without receiving user
> complaints about not being able to send the latest cute kitty pictures
> to their whole addressbook?
>
> Are there per-sender limits that can/should be applied? And is there a
> way I can be notified of a suspicious condition - without manually
> monitoring the queue?
>
> --
> Daniel
>

You might like to consider an ACL, or something like
http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender
to limit (forged) outbound emails from domains you don't control.

Allen C

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

Daniel L. Miller
In reply to this post by Wietse Venema

On 2017-06-23 17:11, [hidden email] wrote:

> Daniel Miller:
>> I had a couple of accounts with too simple passwords hacked. And
>> obviously
>> my mail server is entirely too efficient - I think about 50k spams got
>> blasted out before I caught it (because we got in the DNSBL's).
>>
>> Separate from improving the password security - what can I do to limit
>> the
>> damage a compromised account can cause? Without receiving user
>> complaints
>> about not being able to send the latest cute kitty pictures to their
>> whole
>> addressbook?
>>
>> Are there per-sender limits that can/should be applied? And is there a
>> way
>> I can be notified of a suspicious condition - without manually
>> monitoring
>> the queue?
>
> Search for "postfix policy rate limit"
>
> Wietse

The bulk of the results I receive from that refer to external policy
daemons. ASSP can probably handle that (I'm looking) but I was hoping
for something more Postfix-specific. I did come across references to
some parameters I haven't used before - including

smtpd_client_connection_count_limit
smtpd_client_connection_rate_limit

which I have presently set to 5 - haven't done any testing to see if
that will have any impact.

If there's another reference I should consult please tell me.

---
Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

Wietse Venema
Wietse:
> Search for "postfix policy rate limit"

Daniel Miller:
> The bulk of the results I receive from that refer to external policy
> daemons.

Yes, that was the idea.

> smtpd_client_connection_count_limit
> smtpd_client_connection_rate_limit

Two problems:

- You might want to look into smtpd_client_auth_rate_limit and
  smtpd_client_message_rate_limit.

- The smtpd_client_ settings assume that badness comes from a small
  number of IP addresses. That is usually not the case with stolen
  credentials.

> If there's another reference I should consult please tell me.

Absent other information, a policy daemon is the solution
that I would recommend.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Limit the damage of a hacked sender acount

Noel Jones-2
In reply to this post by Daniel L. Miller
On 6/26/2017 1:39 PM, Daniel Miller wrote:

>
> On 2017-06-23 17:11, [hidden email] wrote:
>> Daniel Miller:
>>> I had a couple of accounts with too simple passwords hacked. And
>>> obviously
>>> my mail server is entirely too efficient - I think about 50k
>>> spams got
>>> blasted out before I caught it (because we got in the DNSBL's).
>>>
>>> Separate from improving the password security - what can I do to
>>> limit the
>>> damage a compromised account can cause? Without receiving user
>>> complaints
>>> about not being able to send the latest cute kitty pictures to
>>> their whole
>>> addressbook?
>>>
>>> Are there per-sender limits that can/should be applied? And is
>>> there a way
>>> I can be notified of a suspicious condition - without manually
>>> monitoring
>>> the queue?
>>
>> Search for "postfix policy rate limit"
>>
>>     Wietse
>
> The bulk of the results I receive from that refer to external policy
> daemons.

Yes, that's the place to look. I recommend postfwd, but many of the
policy services can do the job nicely.
http://postfwd.org/
Some other policy services:
http://www.postfix.org/addon.html#policy

You can set the policy service to either reject/defer/hold messages
over some limit rate, and also notify you when that happens.
Postfwd (and probably some of the others) can trigger an external
script to do stuff such as temporarily disable a user account.


> ASSP can probably handle that (I'm looking) but I was
> hoping for something more Postfix-specific.

ASSP is a proxy, not a policy service. I don't care for anything
installed as a proxy in front of postfix.  I strongly prefer for
postfix to do the dirty work of talking to the public internet.


> I did come across
> references to some parameters I haven't used before - including
>
> smtpd_client_connection_count_limit
> smtpd_client_connection_rate_limit
>
> which I have presently set to 5 - haven't done any testing to see if
> that will have any impact.
>
> If there's another reference I should consult please tell me.

The smtpd_client_**_limit parameters are intended for preventing
denial of service from a broken client rather than spam or hacked
account mitigation.

In particular, these parameters must be set high enough that legit
mail never triggers the protection, as that will cause unpredictable
and possibly large delays in delivery, including the possibility
that some mail never gets delivered.  Use with caution.



  -- Noel Jones

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Loading...