Re: Jenkins amplification

[Christopher Morrow <morrowc.lists () gmail com>]

On Mon, Feb 3, 2020 at 2:34 PM Matt Harris <matt () netfire net> wrote:

> On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow <
> morrowc.lists () gmail com> wrote:
>
> > Sorry, to be a little less flippant and a bit more productive:
> >   "I don't think every remote endpoint needs full access (or even some
> > compromise based on how well you can/can't scale your VPN box's
> > policies) access to the internal network. I think you don't even want
> > to provide this access based on some loose ideas about 'ip address'
> > and 'vpn identity'."
>
> This isn't particularly difficult or costly to do right, though. pfSense
> on a VM with relatively minimal resources running your VPNs works very well
> and can easily be configured to authenticate against, for example, LDAP as
> well. It also has a convenient firewall configuration user interface that's
> very straight-forward, so you don't need some highly-paid network
> engineering guru to manage the thing, either, so you can associate a given
> identity with a

My experience, and granted it's fairly scoped, is that this sort of thing
works fine for a relatively small set of 'persons' and 'resources'.
Soon it gets very messy to say: "Bob can access A, B, D not C, ....." "Jane
can access X, Y, Z, A not B"...

adding groups of people is fine, then you will need (eventually) to split
those groups, or provide scoped access to part of the group(s).
In the end, ick, this is 'hard' and the set of rules can really get large,
it ends up being about the cross-product of #users * #resources.

now, make the solution redundant and geographically redundant, and keep the
config in sync, and open that to your helpdesk folk to manage, and provide
compliance reporting/etc.

given address and then apply firewall rules right at that VPN border in
> addition to the other access controls that you should have in place
> upstream. Certainly giving full access to everyone is overkill,
> unnecessary, and can be problematic for obvious reasons - but at the same
> time, we're talking about back doors here when many of the same folks
> worried about these back doors also have wide open front doors at the same
> time.

certainly a more holistic version of the story is correct.
the relatively flippant answer way-back-up-list of: "vpn"
though is, I think:
  1) naive
  2) destructive to the cause
  3) not a simple as the 3 letters implies
  4) wrong, very, very wrong.

but of course: "your network, your choices" just make sure you walk in with
both eyes open and the appropriate riot gear installed.