Killing user's session

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

Killing user's session

Edwin Marqe
Hello,

Recently, we've had an issue with a stolen password of one of our
users, resulting in a few junk mails sent out. Fortunately, we could
change the user's password reasonably fast and it didn't do any bigger
harm. However, after changing the password, the user was still able to
continue sending junk mail for minimally 20 seconds, after which we
restarted Postfix.

I assume this happens because the user took advantage of the opened
session which won't require re-authenticate and continued sending
those mails.

Is there a Postfix specific command that would end/kill a user's
session? If not, any workaround that would disconnect that user? I've
been trying to find something regarding this in the documentation but
found nothing.

Thank you.

Edwin
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

lists@rhsoft.net


Am 24.08.2014 um 17:52 schrieb Edwin Marqe:

> Recently, we've had an issue with a stolen password of one of our
> users, resulting in a few junk mails sent out. Fortunately, we could
> change the user's password reasonably fast and it didn't do any bigger
> harm. However, after changing the password, the user was still able to
> continue sending junk mail for minimally 20 seconds, after which we
> restarted Postfix.
>
> I assume this happens because the user took advantage of the opened
> session which won't require re-authenticate and continued sending
> those mails.
>
> Is there a Postfix specific command that would end/kill a user's
> session? If not, any workaround that would disconnect that user? I've
> been trying to find something regarding this in the documentation but
> found nothing

if you only reload -> as expected, it is intended to reload
configuration but not kill running operations

if you really restart it is impossible that any session
survives - how should it - the processes are terminated
and so all connections
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Edwin Marqe
Yes, I know that restarting everything ends up, which is what we
finally did, but I was looking for some kind of command or at least a
way of ending a specific user's session without restarting Postfix, as
this domain handles a really big amount of traffic and seems overkill
restart the whole Postfix for just one user.

2014-08-24 16:56 GMT+01:00 [hidden email] <[hidden email]>:

>
>
> Am 24.08.2014 um 17:52 schrieb Edwin Marqe:
>> Recently, we've had an issue with a stolen password of one of our
>> users, resulting in a few junk mails sent out. Fortunately, we could
>> change the user's password reasonably fast and it didn't do any bigger
>> harm. However, after changing the password, the user was still able to
>> continue sending junk mail for minimally 20 seconds, after which we
>> restarted Postfix.
>>
>> I assume this happens because the user took advantage of the opened
>> session which won't require re-authenticate and continued sending
>> those mails.
>>
>> Is there a Postfix specific command that would end/kill a user's
>> session? If not, any workaround that would disconnect that user? I've
>> been trying to find something regarding this in the documentation but
>> found nothing
>
> if you only reload -> as expected, it is intended to reload
> configuration but not kill running operations
>
> if you really restart it is impossible that any session
> survives - how should it - the processes are terminated
> and so all connections
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Viktor Dukhovni
In reply to this post by Edwin Marqe
On Sun, Aug 24, 2014 at 04:52:35PM +0100, Edwin Marqe wrote:

> Is there a Postfix specific command that would end/kill a user's
> session? If not, any workaround that would disconnect that user? I've
> been trying to find something regarding this in the documentation but
> found nothing.

Postfix 2.11 or later has a new feature:

    http://www.postfix.org/postconf.5.html#check_sasl_access

If your relay restrictions look like:

    main.cf:
        indexed = ${default_database_type}:${config_directory}/
        smtpd_relay_restrictions =
            check_sasl_access ${indexed}sasl-access,
            permit_sasl_authenticated,
            permit_mynetworks,
            reject_unauth_destination

(before any user account is compromised), then once an account
is hijacked:

    sasl-access:
        [hidden email] REJECT 5.7.1 Your login is compromised.

    # cd /etc/postfix; postmap sasl-access

The relay check is performed for every message, even for
established connections.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

lists@rhsoft.net
In reply to this post by Edwin Marqe
netstat, ps, lsof, kill........

you need to find out the PID of the smtpd process

honestly it's not worth because if what you describes
you have more imporant problems to solve and restart
postfix even while incoming mail flows is a no-brainer
because it would be re-tried by the sender

Am 24.08.2014 um 18:02 schrieb Edwin Marqe:

> Yes, I know that restarting everything ends up, which is what we
> finally did, but I was looking for some kind of command or at least a
> way of ending a specific user's session without restarting Postfix, as
> this domain handles a really big amount of traffic and seems overkill
> restart the whole Postfix for just one user.
>
> 2014-08-24 16:56 GMT+01:00 [hidden email] <[hidden email]>:
>> Am 24.08.2014 um 17:52 schrieb Edwin Marqe:
>>> Recently, we've had an issue with a stolen password of one of our
>>> users, resulting in a few junk mails sent out. Fortunately, we could
>>> change the user's password reasonably fast and it didn't do any bigger
>>> harm. However, after changing the password, the user was still able to
>>> continue sending junk mail for minimally 20 seconds, after which we
>>> restarted Postfix.
>>>
>>> I assume this happens because the user took advantage of the opened
>>> session which won't require re-authenticate and continued sending
>>> those mails.
>>>
>>> Is there a Postfix specific command that would end/kill a user's
>>> session? If not, any workaround that would disconnect that user? I've
>>> been trying to find something regarding this in the documentation but
>>> found nothing
>>
>> if you only reload -> as expected, it is intended to reload
>> configuration but not kill running operations
>>
>> if you really restart it is impossible that any session
>> survives - how should it - the processes are terminated
>> and so all connections
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Edwin Marqe
In reply to this post by Viktor Dukhovni
That's exactly what I was looking for, thank you so much guys!

2014-08-24 17:06 GMT+01:00 Viktor Dukhovni <[hidden email]>:

> On Sun, Aug 24, 2014 at 04:52:35PM +0100, Edwin Marqe wrote:
>
>> Is there a Postfix specific command that would end/kill a user's
>> session? If not, any workaround that would disconnect that user? I've
>> been trying to find something regarding this in the documentation but
>> found nothing.
>
> Postfix 2.11 or later has a new feature:
>
>     http://www.postfix.org/postconf.5.html#check_sasl_access
>
> If your relay restrictions look like:
>
>     main.cf:
>         indexed = ${default_database_type}:${config_directory}/
>         smtpd_relay_restrictions =
>             check_sasl_access ${indexed}sasl-access,
>             permit_sasl_authenticated,
>             permit_mynetworks,
>             reject_unauth_destination
>
> (before any user account is compromised), then once an account
> is hijacked:
>
>     sasl-access:
>         [hidden email] REJECT 5.7.1 Your login is compromised.
>
>     # cd /etc/postfix; postmap sasl-access
>
> The relay check is performed for every message, even for
> established connections.
>
> --
>         Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

D'Arcy Cain
In reply to this post by Viktor Dukhovni
On Sun, 24 Aug 2014 16:06:36 +0000
Viktor Dukhovni <[hidden email]> wrote:

> Postfix 2.11 or later has a new feature:
>
>     http://www.postfix.org/postconf.5.html#check_sasl_access
>
> If your relay restrictions look like:
>
>     main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtpd_relay_restrictions =
>    check_sasl_access ${indexed}sasl-access,
>    permit_sasl_authenticated,
>    permit_mynetworks,
>    reject_unauth_destination
>
> (before any user account is compromised), then once an account
> is hijacked:
>
>     sasl-access:
> [hidden email] REJECT 5.7.1 Your login is compromised.

This is a particularly good solution as it allows the user to continue
receiving email so that you can send them them a message explaining
exactly what the problem is.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:[hidden email]
VoIP: sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Viktor Dukhovni
In reply to this post by lists@rhsoft.net
On Sun, Aug 24, 2014 at 06:06:52PM +0200, [hidden email] wrote:

> netstat, ps, lsof, kill........
>
> you need to find out the PID of the smtpd process

That can have unintended consequences (the smtpd(8) service might
be throttled).  A restart is better than manually killing specific
Postfix daemons.

With 2.11 or later, there is a better approach (already posted).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Charles Sprickman
In reply to this post by D'Arcy Cain

On Aug 24, 2014, at 12:18 PM, D'Arcy J.M. Cain <[hidden email]> wrote:

> On Sun, 24 Aug 2014 16:06:36 +0000
> Viktor Dukhovni <[hidden email]> wrote:
>> Postfix 2.11 or later has a new feature:
>>
>>    http://www.postfix.org/postconf.5.html#check_sasl_access
>>
>> If your relay restrictions look like:
>>
>>    main.cf:
>> indexed = ${default_database_type}:${config_directory}/
>> smtpd_relay_restrictions =
>>    check_sasl_access ${indexed}sasl-access,
>>    permit_sasl_authenticated,
>>    permit_mynetworks,
>>    reject_unauth_destination
>>
>> (before any user account is compromised), then once an account
>> is hijacked:
>>
>>    sasl-access:
>> [hidden email] REJECT 5.7.1 Your login is compromised.
>
> This is a particularly good solution as it allows the user to continue
> receiving email so that you can send them them a message explaining
> exactly what the problem is.

And I assume this can be sql-backed, correct?  So it should be easy
to build a web-based tool for staff to nuke/un-nuke account once the
issue has been addressed.


Charles

>
> --
> D'Arcy J.M. Cain
> System Administrator, Vex.Net
> http://www.Vex.Net/ IM:[hidden email]
> VoIP: sip:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Wietse Venema
CSS:

> >> If your relay restrictions look like:
> >>
> >>    main.cf:
> >> indexed = ${default_database_type}:${config_directory}/
> >> smtpd_relay_restrictions =
> >>    check_sasl_access ${indexed}sasl-access,
> >>    permit_sasl_authenticated,
> >>    permit_mynetworks,
> >>    reject_unauth_destination
> >>
> >> (before any user account is compromised), then once an account
> >> is hijacked:
> >>
> >>    sasl-access:
> >> [hidden email] REJECT 5.7.1 Your login is compromised.
> >
> > This is a particularly good solution as it allows the user to continue
> > receiving email so that you can send them them a message explaining
> > exactly what the problem is.
>
> And I assume this can be sql-backed, correct?  So it should be easy
> to build a web-based tool for staff to nuke/un-nuke account once the
> issue has been addressed.

Correct. To estimate the SQL query load, there will be one query
per "RCPT TO" command.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

lists@rhsoft.net

Am 24.08.2014 um 21:11 schrieb Wietse Venema:

> CSS:
>>>> If your relay restrictions look like:
>>>>
>>>>    main.cf:
>>>> indexed = ${default_database_type}:${config_directory}/
>>>> smtpd_relay_restrictions =
>>>>    check_sasl_access ${indexed}sasl-access,
>>>>    permit_sasl_authenticated,
>>>>    permit_mynetworks,
>>>>    reject_unauth_destination
>>>>
>>>> (before any user account is compromised), then once an account
>>>> is hijacked:
>>>>
>>>>    sasl-access:
>>>> [hidden email] REJECT 5.7.1 Your login is compromised.
>>>
>>> This is a particularly good solution as it allows the user to continue
>>> receiving email so that you can send them them a message explaining
>>> exactly what the problem is.
>>
>> And I assume this can be sql-backed, correct?  So it should be easy
>> to build a web-based tool for staff to nuke/un-nuke account once the
>> issue has been addressed.
>
> Correct. To estimate the SQL query load, there will be one query
> per "RCPT TO" command

how does that work with "smtpd_sasl_type = dovecot" because in
case of a failed SASL logins you have random crap in the maillog
but not the username?

warning: 1-171-63-28.dynamic.hinet.net[1.171.63.28]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: chello062178066223.23.11.tuwien.teleweb.at[62.178.66.223]: SASL CRAM-MD5 authentication failed:
PDAyNzA5ODU4MzIwNTE0MTkuMTQwODkwMzMyMEBtYWlsLnRoZWxvdW5nZS5uZXQ+

so if the above feature works why postfix don't log the username at all?
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Viktor Dukhovni
On Sun, Aug 24, 2014 at 09:24:57PM +0200, [hidden email] wrote:

> so if the above feature works why postfix don't log the username at all?

The feaure in question allows one to block in real-time the access
of users that are using already authenticated established sessions.

Whatever your question is about, it is something else.

[ As someone pointed out, one might even leave the password in place,
potentially allowing the user to read mail and perhaps fix the
problem. ]

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Reinaldo Gil Lima de Carvalho
In reply to this post by Edwin Marqe

2014-08-24 12:52 GMT-03:00 Edwin Marqe <[hidden email]>:

Recently, we've had an issue with a stolen password of one of our
users, resulting in a few junk mails sent out. Fortunately, we could
change the user's password reasonably fast and it didn't do any bigger
harm. However, after changing the password, the user was still able to
continue sending junk mail for minimally 20 seconds, after which we
restarted Postfix.

I assume this happens because the user took advantage of the opened
session which won't require re-authenticate and continued sending
those mails.

Is there a Postfix specific command that would end/kill a user's
session? If not, any workaround that would disconnect that user? I've
been trying to find something regarding this in the documentation but
found nothing.


Saslauthd credentials cache is enabled? (looks for '-c' option saslauthd daemon)

--
Reinaldo Gil Lima de Carvalho


Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

lists-3
In reply to this post by Viktor Dukhovni
On Mon, August 25, 2014 2:06 am, Viktor Dukhovni wrote:

> If your relay restrictions look like:
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtpd_relay_restrictions = check_sasl_access ${indexed}sasl-access,
> permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

I have smtpd_recipient_restrictions like below:
so, anywhere prior to "permit_sasl_authenticated" is OK, yes?


-------------------------------
smtpd_recipient_restrictions =.
 reject_unknown_sender_domain,.
 reject_unknown_recipient_domain,.
 reject_non_fqdn_sender,.
 reject_non_fqdn_recipient,.
 reject_unlisted_recipient,.
 check_policy_service inet:127.0.0.1:7777,.
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_recipient_access hash:/etc/postfix/recipient_no_checks,
 check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
 check_helo_access hash:/etc/postfix/helo_checks,
 check_sender_access hash:/etc/postfix/sender_checks,
 check_client_access hash:/etc/postfix/client_checks,
 check_client_access pcre:/etc/postfix/client_checks.pcre,
 reject_rbl_client zen.spamhaus.org,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
 reject_rbl_client psbl.surriel.com,
 reject_rhsbl_sender dsn.rfc-ignorant.org,
 check_policy_service inet:127.0.0.1:10031



Reply | Threaded
Open this post in threaded view
|

Re: Killing user's session

Viktor Dukhovni
On Thu, Aug 28, 2014 at 01:17:06PM +1000, [hidden email] wrote:
> On Mon, August 25, 2014 2:06 am, Viktor Dukhovni wrote:
>
> > If your relay restrictions look like:
> > main.cf:
> > indexed = ${default_database_type}:${config_directory}/
> > smtpd_relay_restrictions = check_sasl_access ${indexed}sasl-access,
> > permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Since you need Postfix 2.11, use relay restrictions as recommended.  Then
put just anti-spam stuff in the recipient restrictions, after any whitelists
for anti-spam (rather than anti-relay).

--
        Viktor.