On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert <darix at 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 :)
On 27.09.2017 20:14, Mark Moseley wrote:> On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert <darix at 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
On Wed, Sep 27, 2017 at 10:06 PM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote:> > > On 27.09.2017 20:14, Mark Moseley wrote: > > On Wed, Sep 27, 2017 at 10:03 AM, Marcus Rueckert <darix at 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?