[j-nsp] Multicast through a switch

2018-01-08 Thread Chris Adams
We have some connections using multicast to pass a video feed.  Right
now, it is just VPLS through our routers from endpoint to endpoint; the
connections are all static (no IGMP running on our routers and AFAIK
it's all static at the source and destination, so no IGMP to snoop).

Now we're trying to pass the feed through a VLAN to a new connection
through a switch (a VLAN on a trunk from our router to a VLAN on another
trunk to the transport carrier), but we're not sure how to get the
switch to pass the traffic.  I guess there's something we need to
configure static on the switch, but I don't know what.

This is all Juniper (MX routers and EX switches).  I'm not that
knowledgeable about multicast, so I don't know what to look at.  Thanks
for any pointers/help.

-- 
Chris Adams 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] [c-nsp] Meltdown and Spectre

2018-01-08 Thread Alain Hebert

    If someone can sniff your authentication...

        You're in deep trouble.

    Also for 2018, about dropping using whataboutdisms.  It is clear 
that  those, oddly timed, flaws do not affect properly configured JNP 
devices.


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 01/08/18 12:11, Chuck Anderson wrote:

Umm, you type the password into the box, right?  The box stores that password 
in memory so that it can build a TACACS+ request packet to send to the server?  
Unless you are using SSH keys in lieu of passwords.

On Mon, Jan 08, 2018 at 05:16:01PM +0100, Sebastian Becker wrote:

The password will not be seen on the box itself so no problem. The users are 
tacacs+ authorized/authenticated.
Most scenarios are much easier to accomplish by using the already granted 
rights on the boxes per user then using these kinds of attack vectors opened by 
Meltdown and Spectre.

Our boxes simply do not run other code than that what is delivered by the 
vendors.

—
Sebastian Becker
s...@lab.dtag.de


Am 08.01.2018 um 09:32 schrieb Thilo Bangert :

Den 06-01-2018 kl. 19:49 skrev Sebastian Becker:

Same here. User that have access are implicit trusted.

You do have individual user accounts on the equipment, right?

The idea of having secure individual logins goes down the drain with Meltdown 
and Spectre. You want to be sure that a person logged into a box cannot snoop 
the password of a co-worker.

Meltdown and Spectre are relevant on all affected computing equipment.


So no need for panic.

The usefulness of panic has been degrading the past couple of thousand years ;-)

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [c-nsp] Meltdown and Spectre

2018-01-08 Thread Chuck Anderson
Umm, you type the password into the box, right?  The box stores that password 
in memory so that it can build a TACACS+ request packet to send to the server?  
Unless you are using SSH keys in lieu of passwords.

On Mon, Jan 08, 2018 at 05:16:01PM +0100, Sebastian Becker wrote:
> The password will not be seen on the box itself so no problem. The users are 
> tacacs+ authorized/authenticated.
> Most scenarios are much easier to accomplish by using the already granted 
> rights on the boxes per user then using these kinds of attack vectors opened 
> by Meltdown and Spectre.
> 
> Our boxes simply do not run other code than that what is delivered by the 
> vendors.
> 
> — 
> Sebastian Becker
> s...@lab.dtag.de
> 
> > Am 08.01.2018 um 09:32 schrieb Thilo Bangert :
> > 
> > Den 06-01-2018 kl. 19:49 skrev Sebastian Becker:
> >> Same here. User that have access are implicit trusted.
> > 
> > You do have individual user accounts on the equipment, right?
> > 
> > The idea of having secure individual logins goes down the drain with 
> > Meltdown and Spectre. You want to be sure that a person logged into a box 
> > cannot snoop the password of a co-worker.
> > 
> > Meltdown and Spectre are relevant on all affected computing equipment.
> > 
> > > So no need for panic.
> > 
> > The usefulness of panic has been degrading the past couple of thousand 
> > years ;-)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [c-nsp] Meltdown and Spectre

2018-01-08 Thread Sebastian Becker
The password will not be seen on the box itself so no problem. The users are 
tacacs+ authorized/authenticated.
Most scenarios are much easier to accomplish by using the already granted 
rights on the boxes per user then using these kinds of attack vectors opened by 
Meltdown and Spectre.

Our boxes simply do not run other code than that what is delivered by the 
vendors.

— 
Sebastian Becker
s...@lab.dtag.de

> Am 08.01.2018 um 09:32 schrieb Thilo Bangert :
> 
> Den 06-01-2018 kl. 19:49 skrev Sebastian Becker:
>> Same here. User that have access are implicit trusted.
> 
> You do have individual user accounts on the equipment, right?
> 
> The idea of having secure individual logins goes down the drain with Meltdown 
> and Spectre. You want to be sure that a person logged into a box cannot snoop 
> the password of a co-worker.
> 
> Meltdown and Spectre are relevant on all affected computing equipment.
> 
> > So no need for panic.
> 
> The usefulness of panic has been degrading the past couple of thousand years 
> ;-)
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Meltdown and Spectre

2018-01-08 Thread Misak Khachatryan
Hi,

although i think this is theoretical only discussion, but

If JavaScript on a browser can do it, I think at least python script
will do it. And it's not a problem to run it.


Best regards,
Misak Khachatryan


On Mon, Jan 8, 2018 at 3:15 PM, Ola Thoresen  wrote:
> On 08. jan. 2018 12:10, Saku Ytti wrote:
>
>> On 8 January 2018 at 12:58, Benoit Plessis  wrote:
>>
>>> I can SCP any binary i want on any JunOS platform i own (EX,SRX,QFX),
>>> QFX 5100 let you run arbitrary VM !
>> Pretty sure Gert meant that the binaries need to be signed since maybe
>> last 10years.
>> But I think if you can configure the box, you can change rootPW, turn
>> off signature verification and boot the box, unsure.
>
> I don't think you can turn off signature verification.
>
> "Juniper Networks routing platforms run only binaries supplied by
> Juniper Networks, and currently do not support third-party binaries.
> Each Junos OS image includes a digitally signed manifest of executables
> that are registered with the system only if the signature can be
> validated. Junos OS will not execute any binary without a registered
> signature. This feature protects the system against unauthorized
> software and activity that might compromise the integrity of your device."
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-one-software-overview.html
>
> And for brewity.  I just uploaded a pre-compiled version of "ls" to a
> juniper device, and I am not allowed to run it.
>
>  > start shell
> % chmod 755 /var/tmp/ls
> % /var/tmp/ls
> /var/tmp/ls: Authentication error.
>
> You can run your own shell-scripts through /sbin/sh, but I do not think
> that is enough to get any use out of these bugs:
>
> % ./test.sh
> ./test.sh: Authentication error.
>
> But:
>
> % sh test.sh
> Test
>
>
>
>> At any rate, I think it's uninteresting and unimportant topic, if you
>> can't trust people configuring your network, it's decidedly HR problem
>> and no amount of code or hardware will fix that.
>>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Meltdown and Spectre

2018-01-08 Thread Ola Thoresen

On 08. jan. 2018 12:10, Saku Ytti wrote:


On 8 January 2018 at 12:58, Benoit Plessis  wrote:


I can SCP any binary i want on any JunOS platform i own (EX,SRX,QFX),
QFX 5100 let you run arbitrary VM !

Pretty sure Gert meant that the binaries need to be signed since maybe
last 10years.
But I think if you can configure the box, you can change rootPW, turn
off signature verification and boot the box, unsure.


I don't think you can turn off signature verification.

"Juniper Networks routing platforms run only binaries supplied by 
Juniper Networks, and currently do not support third-party binaries. 
Each Junos OS image includes a digitally signed manifest of executables 
that are registered with the system only if the signature can be 
validated. Junos OS will not execute any binary without a registered 
signature. This feature protects the system against unauthorized 
software and activity that might compromise the integrity of your device."


https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-one-software-overview.html

And for brewity.  I just uploaded a pre-compiled version of "ls" to a 
juniper device, and I am not allowed to run it.


> start shell
% chmod 755 /var/tmp/ls
% /var/tmp/ls
/var/tmp/ls: Authentication error.

You can run your own shell-scripts through /sbin/sh, but I do not think 
that is enough to get any use out of these bugs:


% ./test.sh
./test.sh: Authentication error.

But:

% sh test.sh
Test




At any rate, I think it's uninteresting and unimportant topic, if you
can't trust people configuring your network, it's decidedly HR problem
and no amount of code or hardware will fix that.



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Meltdown and Spectre

2018-01-08 Thread Saku Ytti
On 8 January 2018 at 12:58, Benoit Plessis  wrote:

> I can SCP any binary i want on any JunOS platform i own (EX,SRX,QFX),
> QFX 5100 let you run arbitrary VM !

Pretty sure Gert meant that the binaries need to be signed since maybe
last 10years.
But I think if you can configure the box, you can change rootPW, turn
off signature verification and boot the box, unsure.

At any rate, I think it's uninteresting and unimportant topic, if you
can't trust people configuring your network, it's decidedly HR problem
and no amount of code or hardware will fix that.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Meltdown and Spectre

2018-01-08 Thread Benoit Plessis
Le 08/01/2018 à 10:18, Gert Doering a écrit :
> Hi,
>
> On Mon, Jan 08, 2018 at 10:13:16AM +0100, Thilo Bangert wrote:
>>> Only if said person can execute *arbitrary* code.  Which you can't on my
>>> routers, no matter what sort of account I'm giving you.
>> You mean like
>>
>> $ start shell
> This is not arbirary code - no way to do the needed precision timers
> in shell.  And JunOS does not let you upload *binaries* (or compile
> JavaScript into machine code).

How so ?

I can SCP any binary i want on any JunOS platform i own (EX,SRX,QFX),
QFX 5100 let you run arbitrary VM !

Pretty sure an update or two would be most usefull ...



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Meltdown and Spectre

2018-01-08 Thread Gert Doering
Hi,

On Mon, Jan 08, 2018 at 10:13:16AM +0100, Thilo Bangert wrote:
> > Only if said person can execute *arbitrary* code.  Which you can't on my
> > routers, no matter what sort of account I'm giving you.
> You mean like
> 
> $ start shell

This is not arbirary code - no way to do the needed precision timers
in shell.  And JunOS does not let you upload *binaries* (or compile
JavaScript into machine code).

> Fine if you have that disabled. And of course, assuming there a no other 
> bugs in the software stack.

Please try to understand how Meltdown and Spectre work before spreading
FUD.

gert

-- 
now what should I write here...

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Meltdown and Spectre

2018-01-08 Thread Thilo Bangert

Hi,



Only if said person can execute *arbitrary* code.  Which you can't on my
routers, no matter what sort of account I'm giving you.



You mean like

$ start shell

Fine if you have that disabled. And of course, assuming there a no other 
bugs in the software stack.


Thilo
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] [c-nsp] Meltdown and Spectre

2018-01-08 Thread Gert Doering
Hi,

On Mon, Jan 08, 2018 at 09:32:23AM +0100, Thilo Bangert wrote:
> Den 06-01-2018 kl. 19:49 skrev Sebastian Becker:
> > Same here. User that have access are implicit trusted.
> 
> You do have individual user accounts on the equipment, right?
> 
> The idea of having secure individual logins goes down the drain with 
> Meltdown and Spectre. You want to be sure that a person logged into a 
> box cannot snoop the password of a co-worker.

Only if said person can execute *arbitrary* code.  Which you can't on my
routers, no matter what sort of account I'm giving you.

gert
-- 
now what should I write here...

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [c-nsp] Meltdown and Spectre

2018-01-08 Thread Thilo Bangert



Den 06-01-2018 kl. 19:49 skrev Sebastian Becker:

Same here. User that have access are implicit trusted.


You do have individual user accounts on the equipment, right?

The idea of having secure individual logins goes down the drain with 
Meltdown and Spectre. You want to be sure that a person logged into a 
box cannot snoop the password of a co-worker.


Meltdown and Spectre are relevant on all affected computing equipment.

> So no need for panic.

The usefulness of panic has been degrading the past couple of thousand 
years ;-)


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp