[j-nsp] protect ssh and telnet

[Tom Storey]

Thinking out loud.

Wouldnt that assume that you always access your REs inband, therefore
only ever connecting to the master? What if you access them out of
band via their ethernet ports. Each RE then needs its own unique key?

I mean, in theory they probably dont (is there anything to stop
multiple machines sharing the same key?), but it would make sense that
each RE has its own unique "identity"?

Or maybe that becomes a knob, shared identity with key in config or
unique stored on disk?

Or perhaps you store master and slave RE keys in config so they switch
during failover, at least then you have a maximum of two keys to
expect for any given box, which is better than n keys depending on how
many REs you go through? Or some combination of both of these?


On 5 April 2016 at 17:34, Saku Ytti <saku at ytti.fi> wrote:
> On 5 April 2016 at 19:18, Tore Anderson <tore at fud.no> wrote:
>
> Hey,
>
>> Speaking only for myself, I'd accept server key change only if it's a
>> device that is known to have been recently replaced/zeroized/etc. I'd
>> *never* accept a key changing without that being expected for some
>> reason known in advance.
>
> Depending on scale of network and position in the organisation this
> may work. But if network has 100 tacacs account, thousands or tens of
> thousands of devices, it may not be realistic to expect everyone of
> the 100 user has good grasp when device is being replaced. Maybe 5 of
> those even understand what SSH keys mean.
> I think secret-in-config is fast remedy to hard problem. People who
> are able to do something smart should be able to disable it, but it
> seems safest default way to work. But it might be too late now for
> that, as everyone has learned to ignore keys and many people have
> toolised the key verification out.
>
>> That's not really true even if you blindly accept any changed/unknown
>> SSH key, because telnet will leak information like login credentials in
>> cleartext to any passive listener while mounting a successful attack on
>> SSH requires MitM capability. That's more difficult to pull off. Also,
>> if you're using SSH keys your login credentials won't leak even if you
>> are successfully MitMed.
>
> I don't really have statistics on how often you are able to passively
> listen but not inject, but logically it does make sense that passive
> listen is more common, but by which margin, I don't know. From
> security point of view I consider SSH Telnet equal when SSH keys are
> not verified. But I still prefer SSH in this scenario, because it's
> easier to mechanise with SSH via exec() channels etc.
>
> --
>   ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp