Re: Ever onward

[Eliot Lear <lear@cisco.com>]

Hi,


> Some form of authentication where the identity can be stolen, yes.
> user/passwords are one example of that.  Operators actually want
> usernames/passwords it seems.  Certainly, I'd always encourage people
> to use public/private keys for reasons like this.  Unfortunately, as
> much as public/private technologies have been around for years real
> people aren't using them much yet.  passwords are still prevalent
> (see also: radius, ...)

I agree.  However, there are two types of accesses contemplated.  An 
operator running a script or a program, and a provisioning/management 
system.  I expect that the authentication for each could be handled 
somewhat differently.  Let's first consider the operator.  One can 
ameliorate the attack with several approaches.  The first is use of OTPs 
and physical keys, such as SecurID or DES Gold/Platinum cards.  It 
doesn't make the attack impossible, but it does make it difficult.

The second way to ameliorate the attack is by disabling the offending 
account in the T+/Radius server.  This may not do anything for systems 
that are already compromised, but through the log you will at least know 
which systems are impacted.

A third approach is to use out of band management, and control access 
into that portion of the network.  If an attack ensues, you determine 
the offending account, disable it at the firewall, and if necessary 
bounce connections, which would blow away all the locks in the protocol.

In the case of an element manager, a way to avoid the attack vector 
entirely is to have the element connect to the EMS.  This opens up 
potential attacks on the EMS, of course.

> Margaret> (2) That access to managed devices from outside the network
> Margaret> via the NETCONF (or the underlying protocol) is not blocked
> Margaret> by the site's firewalls and that the firewalls could not
> Margaret> be easily configured to block this traffic.  So, the only
> Margaret> recourse would be to got to every device and remove the
> Margaret> compromised user.
>
> As currently designed the netconf protocol transports will operate
> over existing ports thus completely preventing firewalls from blocking
> configuration ports at the border.  

I disagree and agree ;-)  NETCONF will use a unique port # for the BEEP 
mapping.  All that having been said, I think if you have to put 
management filters in place at your borders, you've lost.

> I've brought this up multiple
> times during meetings and argued that a default different port should
> be created for each transports which differs from the standard one,
> and the populace has always said "we should just make sure it *can* be
> configured to be on a different port".  So, by default out of the box
> netconf boxes are supposed to accept netconf/ssh over ssh until an
> operator configures it differently.  Thus, a border firewall can't be
> configured to disallow management traffic to the network assuming that
> legitimate ssh connections should be allowed through (which is
> most commonly the case).

Great argument for NETCONF/BEEP.

> Margaret> (2) Why do you assume that the way to fight this attack would
> Margaret> be to go to every device and remove the compromised
> Margaret> userid/password?  Wouldn't the first step be to block
> Margaret> incoming traffic from the attacking system?  Then, of course,
> Margaret> you'd want to clean up the compromised authentication
> Margaret> information.
>
> You make the assumption that the attack can be easily blocked because
> it's coming from a single point of origin.  Unwise considering todays
> attack techniques, which are almost always distributed.

Agree.

Eliot


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>