Re: Jenkins amplification

[Christopher Morrow]

On Tue, Feb 4, 2020 at 11:15 AM Mike Meredith  wrote:
>
> On Mon, 3 Feb 2020 16:13:34 -0500, Christopher Morrow
>  may have written:
> > 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'.
>
> Seeing as managing this sort of thing is my primary job these days ...

 :)

> > it ends up being about the cross-product of #users * #resources.
>
> That's the interesting part of the job - coalescing rules in a way that
> minimises the security impact but maximises the decrease of complexity. If
> you don't, you get an explosion of complexity that results in a set of
> rules (I know of an equivalent organisation that has over 1,000 firewall
> rules) that becomes insanely complex to manage.
>

I think the fact that it's hard to keep all of this going and to
contain the natural spread of destruction (that it takes someone with
a pretty singular foc us) makes my point.

> > certainly a more holistic version of the story is correct.
> > the relatively flippant answer way-back-up-list of: "vpn"
>
> I think that "vpn" is the right answer - it's preferrable to publishing
> services to the entire world that only need to be used by empoyees. But
> it's not cheap or easy.

Weighing the cost/benefit is certainly each org's decision.
having lived without vpn for a long while and under the regime of
authen/author for users with proper token/etc access... I'd not want
my internal network opened to the wilds of vpn users :( (I actively
discourage this at work because there are vanishingly small reasons
why a full network connection is really required by a user at this
point).

anyway, good luck!

Re: Jenkins amplification

[Mike Meredith]

On Mon, 3 Feb 2020 16:13:34 -0500, Christopher Morrow
 may have written:
> 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'.

Seeing as managing this sort of thing is my primary job these days ...

> it ends up being about the cross-product of #users * #resources.

That's the interesting part of the job - coalescing rules in a way that
minimises the security impact but maximises the decrease of complexity. If
you don't, you get an explosion of complexity that results in a set of
rules (I know of an equivalent organisation that has over 1,000 firewall
rules) that becomes insanely complex to manage. 

> certainly a more holistic version of the story is correct.
> the relatively flippant answer way-back-up-list of: "vpn"

I think that "vpn" is the right answer - it's preferrable to publishing
services to the entire world that only need to be used by empoyees. But
it's not cheap or easy. 

-- 
Mike Meredith, University of Portsmouth
Hostmaster, Security, and Chief Systems Engineer
 


pgp9x9K3M8fTy.pgp
Description: OpenPGP digital signature

Re: Jenkins amplification

[Daryl]

On Mon, 3 Feb 2020 10:55:35 -0800 (PST)
Sabri Berisha  wrote:

> - On Feb 3, 2020, at 10:35 AM, Christopher Morrow
> morrowc.li...@gmail.com wrote:
> 
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin 
> > wrote:  
> 
> >> VPN.  
> > 
> > I love it when my home network gets full access to the corporate
> > network!  
> 
> Most places I've worked at issue company controlled laptops with
> company controlled VPN software which will disable all local access
> and even disconnect if you dare to manually change the routing table
> to access the printer in your home office.
> 
> In fact, a too tightly controlled VPN contributed to a 7 figure loss
> during an outage at a company which name shall not be mentioned.
> 
> Your home network should have no access to the corp network. Your
> company issued laptop should.
> 
> Thanks,
> 
> Sabri

That's how our company operates. I went a step further and put all
company issued equipment on it's own vlan at home.

Re: Jenkins amplification

[Large Hadron Collider]

It really depends on how much control the employer really needs. In a 
tightly-knit two-site company where the tech guy probably is the reason the 
boss hired the grunt half way across the province, friends don't generally let 
friends down like that, and you really don't have to have that sort of 
vise-tight control.

On Mon, 3 Feb 2020 10:55:35 -0800 (PST)
Sabri Berisha  wrote:

> - On Feb 3, 2020, at 10:35 AM, Christopher Morrow morrowc.li...@gmail.com 
> wrote:
>
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
>
> >> VPN.
> >
> > I love it when my home network gets full access to the corporate network!
>
> Most places I've worked at issue company controlled laptops with company 
> controlled VPN software which will disable all local access and even 
> disconnect if you dare to manually change the routing table to access the 
> printer in your home office.
>
> In fact, a too tightly controlled VPN contributed to a 7 figure loss during 
> an outage at a company which name shall not be mentioned.
>
> Your home network should have no access to the corp network. Your company 
> issued laptop should.
>
> Thanks,
>
> Sabri


--
Large Hadron Collider 

Re: Jenkins amplification

[Randy Bush]

>>> good golly, so glad everyone's enterprise is a hard candy version of same.
>>> no need for these remote workers, or discontiguous offices, or
>>> 'internet centric workforces'.
>>
>> VPN.
> 
> I love it when my home network gets full access to the corporate network!

make things simpler and L2 tunnel so it's the same LAN.

Re: Jenkins amplification

[Jean | ddostest.me via NANOG]

https://en.wikipedia.org/wiki/PfSense

In November 2017, a World Intellectual Property Organization 
 
panel found that Netgate, the copyright holder of pfSense, had been 
using the domain opnsense.com in bad faith to discredit OPNsense 
, a competing open source 
firewall forked from pfSense. It compelled Netgate to transfer the 
domain to Deciso, the developer of OPNsense.


I was happy with pfsense too, until Netgate bought the copyrights.


On 2020-02-03 15:57, Ryan Hamel wrote:

Jean,

Do you have facts to support this claim?

Signed,

A happy pfSense user.


On Mon, Feb 3, 2020, 12:42 PM Jean | ddostest.me  
via NANOG mailto:nanog@nanog.org>> wrote:


Netgate bought Pfsense and they already started to destroy it.

You should consider to switch to Opnsense.

On 2020-02-03 14:34, Matt Harris wrote:
> fSense on a VM with relatively minimal resources running your VPNs
> works very well

Re: Jenkins amplification

[Christopher Morrow]

On Mon, Feb 3, 2020 at 2:34 PM Matt Harris  wrote:

>
> On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow <
> morrowc.li...@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.

Re: Jenkins amplification

[Ryan Hamel]

Jean,

Do you have facts to support this claim?

Signed,

A happy pfSense user.


On Mon, Feb 3, 2020, 12:42 PM Jean | ddostest.me via NANOG 
wrote:

> Netgate bought Pfsense and they already started to destroy it.
>
> You should consider to switch to Opnsense.
>
> On 2020-02-03 14:34, Matt Harris wrote:
> > fSense on a VM with relatively minimal resources running your VPNs
> > works very well
>

Re: Jenkins amplification

[Jean | ddostest.me via NANOG]

Netgate bought Pfsense and they already started to destroy it.

You should consider to switch to Opnsense.

On 2020-02-03 14:34, Matt Harris wrote:
fSense on a VM with relatively minimal resources running your VPNs 
works very well 

Re: Jenkins amplification

[Michael Thomas]

On 2/3/20 10:48 AM, Christopher Morrow 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'."

Ideally you'd be able to authenticate and authorize and even
account(!) based on a real user-id + passwd + token (2fa thing).
Somethign akin to this:
   https://cloud.google.com/beyondcorp/

maybe using the googz work directly isn't your cup-o-joe(jane?) but...
the idea itself is the point I was aiming for.



So somebody is using the internet as it was originally designed. Will 
miracles never cease.


Mike

Re: Jenkins amplification

[Matt Harris]

On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow 
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 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.

Matt Harris|CIO
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver innovative IT solutions.

Re: Jenkins amplification

[Christopher Morrow]

On Mon, Feb 3, 2020 at 1:55 PM Sabri Berisha  wrote:
>
> - On Feb 3, 2020, at 10:35 AM, Christopher Morrow morrowc.li...@gmail.com 
> wrote:
>
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
>
> >> VPN.
> >
> > I love it when my home network gets full access to the corporate network!
>
> Most places I've worked at issue company controlled laptops with company 
> controlled VPN software which will disable all local access and even 
> disconnect if you dare to manually change the routing table to access the 
> printer in your home office.
>
> In fact, a too tightly controlled VPN contributed to a 7 figure loss during 
> an outage at a company which name shall not be mentioned.
>
> Your home network should have no access to the corp network. Your company 
> issued laptop should.

you have used a bunch of 'should' and 'most' in your explanation.
I do not believe you.

Re: Jenkins amplification

[Matt Harris]

On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow 
wrote:

> On Mon, Feb 3, 2020 at 1:35 PM Christopher Morrow
Matt Harris|CIO
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver innovative IT solutions.

>  wrote:
> >
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
> > >
> > > On Mon, Feb 3, 2020 at 10:24 AM Christopher Morrow
> > >  wrote:
> > > > On Mon, Feb 3, 2020 at 11:45 AM Harald Koch  wrote:
> > > > > Jenkins, like a zillion other developer-oriented tools, should
> never be deployed Internet-facing.
> > > > > Reflection attacks inside an enterprise are handled by HR. :)
> > > >
> > > > good golly, so glad everyone's enterprise is a hard candy version of
> same.
> > > > no need for these remote workers, or discontiguous offices, or
> > > > 'internet centric workforces'.
> > >
> > > VPN.
> >
> > I love it when my home network gets full access to the corporate network!
>
> 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'."
>
> Ideally you'd be able to authenticate and authorize and even
> account(!) based on a real user-id + passwd + token (2fa thing).
> Somethign akin to this:
>   https://cloud.google.com/beyondcorp/
>
> maybe using the googz work directly isn't your cup-o-joe(jane?) but...
> the idea itself is the point I was aiming for.
>

Re: Jenkins amplification

[Sabri Berisha]

- On Feb 3, 2020, at 10:35 AM, Christopher Morrow morrowc.li...@gmail.com 
wrote:

> On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:

>> VPN.
> 
> I love it when my home network gets full access to the corporate network!

Most places I've worked at issue company controlled laptops with company 
controlled VPN software which will disable all local access and even disconnect 
if you dare to manually change the routing table to access the printer in your 
home office.

In fact, a too tightly controlled VPN contributed to a 7 figure loss during an 
outage at a company which name shall not be mentioned.

Your home network should have no access to the corp network. Your company 
issued laptop should.

Thanks,

Sabri

Re: Jenkins amplification

[Christopher Morrow]

On Mon, Feb 3, 2020 at 1:35 PM Christopher Morrow
 wrote:
>
> On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
> >
> > On Mon, Feb 3, 2020 at 10:24 AM Christopher Morrow
> >  wrote:
> > > On Mon, Feb 3, 2020 at 11:45 AM Harald Koch  wrote:
> > > > Jenkins, like a zillion other developer-oriented tools, should never be 
> > > > deployed Internet-facing.
> > > > Reflection attacks inside an enterprise are handled by HR. :)
> > >
> > > good golly, so glad everyone's enterprise is a hard candy version of same.
> > > no need for these remote workers, or discontiguous offices, or
> > > 'internet centric workforces'.
> >
> > VPN.
>
> I love it when my home network gets full access to the corporate network!

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'."

Ideally you'd be able to authenticate and authorize and even
account(!) based on a real user-id + passwd + token (2fa thing).
Somethign akin to this:
  https://cloud.google.com/beyondcorp/

maybe using the googz work directly isn't your cup-o-joe(jane?) but...
the idea itself is the point I was aiming for.

Re: Jenkins amplification

[Christopher Morrow]

On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
>
> On Mon, Feb 3, 2020 at 10:24 AM Christopher Morrow
>  wrote:
> > On Mon, Feb 3, 2020 at 11:45 AM Harald Koch  wrote:
> > > Jenkins, like a zillion other developer-oriented tools, should never be 
> > > deployed Internet-facing.
> > > Reflection attacks inside an enterprise are handled by HR. :)
> >
> > good golly, so glad everyone's enterprise is a hard candy version of same.
> > no need for these remote workers, or discontiguous offices, or
> > 'internet centric workforces'.
>
> VPN.

I love it when my home network gets full access to the corporate network!

Re: Jenkins amplification

[William Herrin]

On Mon, Feb 3, 2020 at 10:24 AM Christopher Morrow
 wrote:
> On Mon, Feb 3, 2020 at 11:45 AM Harald Koch  wrote:
> > Jenkins, like a zillion other developer-oriented tools, should never be 
> > deployed Internet-facing.
> > Reflection attacks inside an enterprise are handled by HR. :)
>
> good golly, so glad everyone's enterprise is a hard candy version of same.
> no need for these remote workers, or discontiguous offices, or
> 'internet centric workforces'.

VPN.



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Jenkins amplification

[Christopher Morrow]

On Mon, Feb 3, 2020 at 11:45 AM Harald Koch  wrote:
>
> Jenkins, like a zillion other developer-oriented tools, should never be 
> deployed Internet-facing.
>
> Reflection attacks inside an enterprise are handled by HR. :)

good golly, so glad everyone's enterprise is a hard candy version of same.
no need for these remote workers, or discontiguous offices, or
'internet centric workforces'.


all fixed!

Re: Jenkins amplification

[Harald Koch]

Jenkins, like a zillion other developer-oriented tools, should never be 
deployed Internet-facing.

Reflection attacks inside an enterprise are handled by HR. :)

-- 
Harald Koch
c...@pobox.com

Jenkins amplification

[Töma Gavrichenkov]

FYI

https://nvd.nist.gov/vuln/detail/CVE-2020-2100
A nice description: https://mobile.twitter.com/Foone/status/1223063275996213248

May you live in interesting times.

Do not postpone a software update if Jenkins is deployed somewhere in
your network.

--
Töma