[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ever onward
At 02:10 PM 2/4/2004 -0800, Wes Hardaker wrote:
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.
When someone is attacking all of my routers via their SSH ports, I do
have a couple of options for blocking this at my firewall -- (1)
block all inbound traffic from the attacker, (2) block all inbound
SSH traffic to my routers, (3) block all inbound traffic of any
kind to my internal routers. Any of these choices would (I think) block
the attack while I removed the compromised user from all of my routers.
Since I have to manage users on my routers when I get new employees, old
ones leave, etc., this shouldn't be that horrible.
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).
I understand your statements, and I will grant that you have far more
security experience than I do. But, it isn't my understanding that
people will want to block all external management access to their
managed devices, since they will want the ability to manage them
remotely. Isn't that the whole point of having secure management
mechanisms, like NETCONF over SSH or NETCONF over BEEP with
appropriate security?
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.
Okay. But, you could (temporarily) shutdown all external SSH access
(or BEEP access) to your routers until the compromised user could be
removed, right?
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/>