[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ever onward
>>>>> On Wed, 04 Feb 2004 15:01:30 -0500, Margaret Wasserman <margaret@thingmagic.com> said:
Margaret> (1) That people will use NETCONF over a protocol that involves
Margaret> typing a userid/password that is also stored on the managed
Margaret> device.
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, ...)
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'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).
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.
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett
--
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/>