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.

EVPN multicast route (multi home case ) implementation / deployment information

[Mankamana Mishra (mankamis) via NANOG]

Folks
Wondering if there is any known implementation of EVPN multihome multicast 
routes which are defined in
https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04

there is some change planned in NLRI , we want to make sure to have solution 
which does work well with existing implementation.

Note:  Discussion involves Nokia, Juniper, Cisco, Arista already. So looking 
for any other vendor who have implementation.


Mankamana

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: The curious case of 159.174.0.0/16

[Sabri Berisha]

- On Feb 1, 2020, at 1:54 PM, Pavel Lunin plu...@plunin.net wrote:

Hi Pavel,

> On Wednesday, January 29, 2020 5:15 PM, Sabri Berisha 
> wrote:
> 
>> I'm surprised about the lack of response from FT/DT though.
> 
> And now multiply this by 3, because DT and ARIN are no better.

I appreciate your contempt for corporate entities. It seems however, that 
you forget one important aspect here: most corporations are carefully
organized to ensure all assets are properly used to generate revenue.

In this case, IP space is an asset which can bring (or secure current)
revenue streams. This is the reason why I'm surprised.

Thanks,

Sabri

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: Starting to Drop Invalids for Customers

[Jakob Heitz (jheitz) via NANOG]

Lukas,

CSCvc84848

Will keep you in the loop too, Lukas.

Regards,
Jakob.

-Original Message-
From: Lukas Tribus  
Sent: Monday, February 3, 2020 12:43 AM
To: Mark Tinka ; Jakob Heitz (jheitz) 
Cc: nanog@nanog.org
Subject: Re: Starting to Drop Invalids for Customers

Hello,

On Tue, 14 Jan 2020 at 07:21, Mark Tinka  wrote:
>  On 13/Jan/20 21:53, Jakob Heitz (jheitz) wrote:
> > Mark,
> >
> > Thanks for bringing this up again.
> > I remember this from nearly 3 years ago when Randy brought it up.
> > A bug was filed, but it disappeared in the woodwork.
> > I have now given it the high priority tag that it should have had initially.
> > Sorry about the mess up.
>
> Many thanks, Jakob, for bumping this. Much appreciated, as I was
> dreading running this through my account team :-).
>
> Most grateful if you can keep us (or me, whichever you prefer) posted on
> the progress of this fix. I am willing to test code to verify things.

I'm also very interested to follow the progress here. Is there a BugID
you guys can share?


Thank you,

Lukas

Re: Recommended DDoS mitigation appliance?

[Javier Juan]

Hi !

I was looking around (a couple years ago) for mitigation appliances
(Riorey, Arbor, F5 and so on) but the best and almost affordable
solution I found was Incapsula/Imperva.
https://docs.imperva.com/bundle/cloud-application-security/page/introducing/network-ddos-monitoring.htm


Basically, You send your flows to Imperva on cloud for analysis. As soon as
they find DDoS attack , they activate mitigation. It´s some kind of
elegant-hybrid solution without on-premise appliances . Just check it out :)

Regards,

JJ



On Sun, Nov 17, 2019 at 11:20 PM Rabbi Rob Thomas  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Hello, NANOG!
>
> I'm in the midst of rebuilding/upgrading our backbone and peering -
> sessions cheerfully accepted :) - and am curious what folks recommend
> in the DDoS mitigation appliance realm?  Ideally it would be capable
> of 10Gbps and circa 14Mpps rate of mitigation.  If you have a
> recommendation, I'd love to hear it and the reasons for it.  If you
> have an alternative to an appliance that has worked well for you
> (we're a mix of Cisco and Juniper), I'm all ears.
>
> Private responses are fine, and I'm happy to summarize back to the
> list if there is interest.
>
> Thank you!
> Rob.
> - --
> Rabbi Rob Thomas   Team Cymru
>"It is easy to believe in freedom of speech for those with whom we
> agree." - Leo McKern
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAl3Rx08ACgkQQ+hhYvqF
> 8o0snw/8CxTOujcodNh/huMXZaUNlMNoNRz3IoPqBiAP9BZomMz9xqlpDW/qvWBF
> xhoJ07C0O0mo5ilNjnPR308uifIBu6ylw02PshOCU06dV0afgtndxGg5AoG9npUV
> 7uCi2afWaf22dq5TwKLut8QPNNQJTRzndX88xJw9MzzoBTemxRtM7ft4H3UhJ0hv
> oKo83FCNZQt36I+GZA9GBJeXM+o0f5h0w6fhRqARzttf6brJZdXgROyIQ7jptGuZ
> N3Yrjk/8RM4XKMnYbtIwl8NS3c0nEGN3ndn+Bz7p2FE7QJrZKonk/o03dvr2kU0Y
> 7gUQliOOzV9EsptVGyLCVyDJSElvXTBaps0giEVZhdmEIDJPWvBc+93j1g7xbmti
> 27lT6+5qBmEN0oKJWxXgtw9/n1yX9vsc7tXlgYDoXGhIlszdB3baRao1tYEp8BBQ
> hTGAULRfHe94tRzvOOQUQIuhzNcK1Q4E2jU6kzBB1wJsBD4zuHk+QIJLSHBmmnka
> VNKlQ+5zP8dmSMBp6k4feqAtt3hy0Bj+34FbdQZYPutIe3VXHEjpWI3jI9vKjhtC
> g7U/9CQIjVUl2APn1IllArpUpETBlNq7dSeJNUN/4Xh+eHglUnEn/m2kFG5mizmP
> d0YvLEVe0/+WzDUz+y3KxDVP5tdJT1VM46FHIgeiB4KrWNGRPUo=
> =uuel
> -END PGP SIGNATURE-
>

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

Re: Starting to Drop Invalids for Customers

[Lukas Tribus]

Hello,

On Tue, 14 Jan 2020 at 07:21, Mark Tinka  wrote:
>  On 13/Jan/20 21:53, Jakob Heitz (jheitz) wrote:
> > Mark,
> >
> > Thanks for bringing this up again.
> > I remember this from nearly 3 years ago when Randy brought it up.
> > A bug was filed, but it disappeared in the woodwork.
> > I have now given it the high priority tag that it should have had initially.
> > Sorry about the mess up.
>
> Many thanks, Jakob, for bumping this. Much appreciated, as I was
> dreading running this through my account team :-).
>
> Most grateful if you can keep us (or me, whichever you prefer) posted on
> the progress of this fix. I am willing to test code to verify things.

I'm also very interested to follow the progress here. Is there a BugID
you guys can share?


Thank you,

Lukas