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