Conditionally disabling auth policy

newer
Securing postfix to dovecot (SASL)...

older
doveadm backup panic, dsync-ibc.c,...

Mark Moseley

27 Sep 2017 27 Sep '17

7:57 p.m.

I've been digging into the auth policy stuff with weakforced lately. There are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can trust, but that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing?

Show replies by date

Marcus Rueckert

27 Sep 27 Sep

8:03 p.m.

On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:

...

I've been digging into the auth policy stuff with weakforced lately. There are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can trust, but that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing?

...

From my config:

  allowed_subnets=newNetmaskGroup()
  allowed_subnets:addMask('fe80::/64')
  allowed_subnets:addMask('127.0.0.0/8')
[snip]
  if (not(allowed_subnets.match(lt.remote)))
  -- do GeoIP check
  end

of course could just skip all checks in that case if really wanted. but you probably want to be careful not to skip too many checks otherwise the attack moves from your imap port e.g. to your webmailer.

darix

-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org

Mark Moseley

8:14 p.m.

On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert darix@opensu.se wrote:

...

On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:

...
I've been digging into the auth policy stuff with weakforced lately. There are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can trust, but that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing?

From my config:
  allowed_subnets=newNetmaskGroup()
  allowed_subnets:addMask('fe80::/64')
  allowed_subnets:addMask('127.0.0.0/8')
[snip]
  if (not(allowed_subnets.match(lt.remote)))
  -- do GeoIP check
  end
of course could just skip all checks in that case if really wanted. but you probably want to be careful not to skip too many checks otherwise the attack moves from your imap port e.g. to your webmailer.

Hi. Yup, I've got my own whitelisting going on, on the wforce side of things. I'm just looking to forgo the 3 HTTP reqs completely to wforce, from the dovecot side, if possible. I've got some internal services that can generate a significant amount of dovecot logins, but it's kind of silly to keep doing auth policy lookups for those internal servers.

To continue the Lua thread, I was thinking I could also drop a local openresty to do some conditional lookups. I.e. if remote IP is known good, a localhost nginx just sends back the response; if not a known good IP, then proxy the req over to the wforce cluster. That might be a bit overkill though :)

Aki Tuomi

28 Sep 28 Sep

8:06 a.m.

On 27.09.2017 20:14, Mark Moseley wrote:

...

On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert darix@opensu.se wrote:

...
On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:

...
I've been digging into the auth policy stuff with weakforced lately. There are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can trust, but that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing? From my config:
  allowed_subnets=newNetmaskGroup()
  allowed_subnets:addMask('fe80::/64')
  allowed_subnets:addMask('127.0.0.0/8')
[snip]
  if (not(allowed_subnets.match(lt.remote)))
  -- do GeoIP check
  end
of course could just skip all checks in that case if really wanted. but you probably want to be careful not to skip too many checks otherwise the attack moves from your imap port e.g. to your webmailer.
Hi. Yup, I've got my own whitelisting going on, on the wforce side of things. I'm just looking to forgo the 3 HTTP reqs completely to wforce, from the dovecot side, if possible. I've got some internal services that can generate a significant amount of dovecot logins, but it's kind of silly to keep doing auth policy lookups for those internal servers.

To continue the Lua thread, I was thinking I could also drop a local openresty to do some conditional lookups. I.e. if remote IP is known good, a localhost nginx just sends back the response; if not a known good IP, then proxy the req over to the wforce cluster. That might be a bit overkill though :) Hi!

Currently it's not possible to disable auth_policy conditionally, although it does sound like a good idea.

You should probably see also if your webmail supports passing the original IP to dovecot using

a01 ID ("X-Original-IP" "1.2.3.4")

before login, which would let you use weakforced in more meaningful way. There are few other fields too that can be used

Aki

Mark Moseley

7:20 p.m.

On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...

On 27.09.2017 20:14, Mark Moseley wrote:

...
On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert darix@opensu.se wrote:

...
On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:

...
I've been digging into the auth policy stuff with weakforced lately. There are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can trust, but that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing? From my config:
  allowed_subnets=newNetmaskGroup()
  allowed_subnets:addMask('fe80::/64')
  allowed_subnets:addMask('127.0.0.0/8')
[snip]
  if (not(allowed_subnets.match(lt.remote)))
  -- do GeoIP check
  end
of course could just skip all checks in that case if really wanted. but you probably want to be careful not to skip too many checks otherwise the attack moves from your imap port e.g. to your webmailer.
Hi. Yup, I've got my own whitelisting going on, on the wforce side of things. I'm just looking to forgo the 3 HTTP reqs completely to wforce, from the dovecot side, if possible. I've got some internal services that can generate a significant amount of dovecot logins, but it's kind of silly to keep doing auth policy lookups for those internal servers.

To continue the Lua thread, I was thinking I could also drop a local openresty to do some conditional lookups. I.e. if remote IP is known good, a localhost nginx just sends back the response; if not a known good IP, then proxy the req over to the wforce cluster. That might be a bit overkill though :) Hi!
Currently it's not possible to disable auth_policy conditionally, although it does sound like a good idea.

You should probably see also if your webmail supports passing the original IP to dovecot using

a01 ID ("X-Original-IP" "1.2.3.4")

before login, which would let you use weakforced in more meaningful way. There are few other fields too that can be used

Aki

Yup, I've got that set up. I've got no problems with short-circuiting the request on the weakforce side quickly, in case of known good ips. Just hoping to avoid some unnecessary auth policy lookups.

Out of curiosity (and I've googled this before), what other fields can be used there?

Aki Tuomi

7:34 p.m.

...

On September 28, 2017 at 7:20 PM Mark Moseley moseleymark@gmail.com wrote:

On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...
On 27.09.2017 20:14, Mark Moseley wrote:

...
On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert darix@opensu.se wrote:

...
On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:

...
I've been digging into the auth policy stuff with weakforced lately. There are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can trust, but that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing? From my config:
  allowed_subnets=newNetmaskGroup()
  allowed_subnets:addMask('fe80::/64')
  allowed_subnets:addMask('127.0.0.0/8')
[snip]
  if (not(allowed_subnets.match(lt.remote)))
  -- do GeoIP check
  end
of course could just skip all checks in that case if really wanted. but you probably want to be careful not to skip too many checks otherwise the attack moves from your imap port e.g. to your webmailer.
Hi. Yup, I've got my own whitelisting going on, on the wforce side of things. I'm just looking to forgo the 3 HTTP reqs completely to wforce, from the dovecot side, if possible. I've got some internal services that can generate a significant amount of dovecot logins, but it's kind of silly to keep doing auth policy lookups for those internal servers.

To continue the Lua thread, I was thinking I could also drop a local openresty to do some conditional lookups. I.e. if remote IP is known good, a localhost nginx just sends back the response; if not a known good IP, then proxy the req over to the wforce cluster. That might be a bit overkill though :) Hi!
Currently it's not possible to disable auth_policy conditionally, although it does sound like a good idea.

You should probably see also if your webmail supports passing the original IP to dovecot using

a01 ID ("X-Original-IP" "1.2.3.4")

before login, which would let you use weakforced in more meaningful way. There are few other fields too that can be used

Aki
Yup, I've got that set up. I've got no problems with short-circuiting the request on the weakforce side quickly, in case of known good ips. Just hoping to avoid some unnecessary auth policy lookups.

Out of curiosity (and I've googled this before), what other fields can be used there?

x-originating-ip - client IP
x-originating-port - client port
x-connected-ip - server IP (like, on proxy)
x-connected-port - server port
x-proxy-ttl - non-negative integer, decremented on each hop, used for loop detection.
x-session-id - session ID, if you want to provide one
x-session-ext-id - session prefix
x-forward- - field to import into passdb during authentication, comes prefixed with forward_. e.g if you set x-forward-username, it comes as forward_username, and can be used like

username=%{forward_username}

Aki

Mark Moseley

10:32 p.m.

On Thu, Sep 28, 2017 at 9:34 AM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...

...
On September 28, 2017 at 7:20 PM Mark Moseley moseleymark@gmail.com wrote:

On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi aki.tuomi@dovecot.fi wrote:

...
On 27.09.2017 20:14, Mark Moseley wrote:

...
On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert darix@opensu.se wrote:

...
On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:

...
I've been digging into the auth policy stuff with weakforced

...
...
...
There

...
are cases (IP ranges, so could be wrapped up in remote {} blocks) where it'd be nice to skip the auth policy (internal hosts that I can

...
...
...
but

...
that are hitting the same servers as the outside world).

Is there any way to disable auth policy, possibly inside a remote{}?

auth_policy_server_url complains that it can't be used inside a remote block, so no dice there. Anything I'm missing? From my config:
  allowed_subnets=newNetmaskGroup()
  allowed_subnets:addMask('fe80::/64')
  allowed_subnets:addMask('127.0.0.0/8')
[snip]
  if (not(allowed_subnets.match(lt.remote)))
  -- do GeoIP check
  end
of course could just skip all checks in that case if really wanted. but you probably want to be careful not to skip too many checks otherwise the attack moves from your imap port e.g. to your webmailer.
Hi. Yup, I've got my own whitelisting going on, on the wforce side of things. I'm just looking to forgo the 3 HTTP reqs completely to wforce, from the dovecot side, if possible. I've got some internal services
lately. trust, that

...
...
can generate a significant amount of dovecot logins, but it's kind of silly to keep doing auth policy lookups for those internal servers.

To continue the Lua thread, I was thinking I could also drop a local openresty to do some conditional lookups. I.e. if remote IP is known good, a localhost nginx just sends back the response; if not a known good IP, then proxy the req over to the wforce cluster. That might be a bit overkill though :) Hi!

Currently it's not possible to disable auth_policy conditionally, although it does sound like a good idea.

You should probably see also if your webmail supports passing the original IP to dovecot using

a01 ID ("X-Original-IP" "1.2.3.4")

before login, which would let you use weakforced in more meaningful way. There are few other fields too that can be used

Aki

Yup, I've got that set up. I've got no problems with short-circuiting the request on the weakforce side quickly, in case of known good ips. Just hoping to avoid some unnecessary auth policy lookups.

Out of curiosity (and I've googled this before), what other fields can be used there?
x-originating-ip - client IP

x-originating-port - client port

x-connected-ip - server IP (like, on proxy)

x-connected-port - server port

x-proxy-ttl - non-negative integer, decremented on each hop, used for loop detection.

x-session-id - session ID, if you want to provide one

x-session-ext-id - session prefix

x-forward- - field to import into passdb during authentication, comes prefixed with forward_. e.g if you set x-forward-username, it comes as forward_username, and can be used like

username=%{forward_username}

The 'forward' stuff is gold. I found that I had to access it like this: %{passwd:forward_<name>}

Is that the right way to use it?

Also (unrelated), I noticed this in the wiki but it's not in the release notes for 2.2.32 (and it sounds super useful):

"Since v2.2.32 it's possible to use conditionals in variable expansion"

Aki Tuomi

29 Sep 29 Sep

9:32 a.m.

On 28.09.2017 22:32, Mark Moseley wrote:

...

On Thu, Sep 28, 2017 at 9:34 AM, Aki Tuomi mailto:aki.tuomi@dovecot.fi> wrote:

> On September 28, 2017 at 7:20 PM Mark Moseley
<moseleymark@gmail.com <mailto:moseleymark@gmail.com>> wrote:
>
>
> On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi
<aki.tuomi@dovecot.fi <mailto:aki.tuomi@dovecot.fi>> wrote:
>
> >
> >
> > On 27.09.2017 20 <tel:27.09.2017%2020>:14, Mark Moseley wrote:
> > > On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert
<darix@opensu.se <mailto:darix@opensu.se>>
> > wrote:
> > >
> > >> On 2017-09-27 16:57:44 +0000, Mark Moseley wrote:
> > >>> I've been digging into the auth policy stuff with
weakforced lately.
> > >> There
> > >>> are cases (IP ranges, so could be wrapped up in remote {}
blocks) where
> > >>> it'd be nice to skip the auth policy (internal hosts that
I can trust,
> > >> but
> > >>> that are hitting the same servers as the outside world).
> > >>>
> > >>> Is there any way to disable auth policy, possibly inside a
remote{}?
> > >>>
> > >>> auth_policy_server_url complains that it can't be used
inside a remote
> > >>> block, so no dice there. Anything I'm missing?
> > >> From my config:
> > >> ```
> > >>   allowed_subnets=newNetmaskGroup()
> > >>   allowed_subnets:addMask('fe80::/64')
> > >>   allowed_subnets:addMask('127.0.0.0/8 <http://127.0.0.0/8>')
> > >> [snip]
> > >>   if (not(allowed_subnets.match(lt.remote)))
> > >>   -- do GeoIP check
> > >>   end
> > >> ```
> > >>
> > >> of course could just skip all checks in that case if really
wanted. but
> > >> you probably want to be careful not to skip too many checks
otherwise
> > >> the attack moves from your imap port e.g. to your webmailer.
> > >>
> > >>
> > >>
> > > Hi. Yup, I've got my own whitelisting going on, on the
wforce side of
> > > things. I'm just looking to forgo the 3 HTTP reqs completely
to wforce,
> > > from the dovecot side, if possible. I've got some internal
services that
> > > can generate a significant amount of dovecot logins, but
it's kind of
> > silly
> > > to keep doing auth policy lookups for those internal servers.
> > >
> > > To continue the Lua thread, I was thinking I could also drop
a local
> > > openresty to do some conditional lookups. I.e. if remote IP
is known
> > good,
> > > a localhost nginx just sends back the response; if not a
known good IP,
> > > then proxy the req over to the wforce cluster. That might be
a bit
> > overkill
> > > though :)
> > Hi!
> >
> > Currently it's not possible to disable auth_policy conditionally,
> > although it does sound like a good idea.
> >
> > You should probably see also if your webmail supports passing the
> > original IP to dovecot using
> >
> > a01 ID ("X-Original-IP" "1.2.3.4")
> >
> > before login, which would let you use weakforced in more
meaningful way.
> > There are few other fields too that can be used
> >
> > Aki
> >
>
> Yup, I've got that set up. I've got no problems with
short-circuiting the
> request on the weakforce side quickly, in case of known good
ips. Just
> hoping to avoid some unnecessary auth policy lookups.
>
> Out of curiosity (and I've googled this before), what other
fields can be
> used there?

* x-originating-ip - client IP
* x-originating-port - client port
* x-connected-ip - server IP (like, on proxy)
* x-connected-port - server port
* x-proxy-ttl - non-negative integer, decremented on each hop,
used for loop detection.
* x-session-id - session ID, if you want to provide one
* x-session-ext-id - session prefix
* x-forward-<any_field_name> - field to import into passdb during
authentication, comes prefixed with forward_. e.g if you set
x-forward-username, it comes as forward_username, and can be used like

username=%{forward_username}

The 'forward' stuff is gold. I found that I had to access it like this: %{passwd:forward_<name>}

Is that the right way to use it?

Also (unrelated), I noticed this in the wiki but it's not in the release notes for 2.2.32 (and it sounds super useful):

"Since v2.2.32 it's possible to use conditionals in variable expansion"

Depends where you use it. In passdb expansion, you can use %{forward_name}. You should use userdb_something=%{forward_something} to move it properly into userdb, you can drop the forward, too. We use this to forward stuff from proxy=>backend.

Conditionals were probably forgotten from release notes.

Aki

2611

Age (days ago)

2613

Last active (days ago)

List overview

7 comments

3 participants

participants (3)

Aki Tuomi
Marcus Rueckert
Mark Moseley

Conditionally disabling auth policy

tags

participants (3)