[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ever onward




Hi Wes,


1) attacker gains access to a poorly kept up machine with netconf
   support and steals a netconf username/password which has limited
   configuration privileges elsewhere but does have locking ability.
   This could be anything from a poorly updated router to a simple
   printer, etc.  Or, social engineering attacks (I've always hated
   that term) is trivial these days (I've called NOCs and had someone
   I didn't know give me a password just because I said I was either
   myself or my boss.  They failed the test).

This attack scenario seems to make several assumptions:


(1) That people will use NETCONF over a protocol that involves
    typing a userid/password that is also stored on the managed
    device.

(2) That access to managed devices from outside the network
    via the NETCONF (or the underlying protocol) is not blocked
    by the site's firewalls and that the firewalls could not
    be easily configured to block this traffic.  So, the only
    recourse would be to got to every device and remove the
    compromised user.

But, these don't seem like reasonable assumptions to me.  My
thoughts on each one:

(1) It is quite possible to use SSH without having a password
    stored on the remote machine (using shared keys), and I think
    that the SSH specs spell out how/why this is more secure than
    using userids/passwords for authentication.  I don't know
    enough about how BEEP handles authentication to know if a
    userid/passwd would be stored on the device -- Eliot?

(2) Why do you assume that the way to fight this attack would
    be to go to every device and remove the compromised
    userid/password?  Wouldn't the first step be to block
    incoming traffic from the attacking system?  Then, of course,
    you'd want to clean up the compromised authentication
    information.

Margaret


-- 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/>