[j-nsp] protect ssh and telnet

[Saku Ytti]

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