[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ever onward
>>>>> On Thu, 05 Feb 2004 13:03:05 -0500, Margaret Wasserman <margaret@thingmagic.com> said:
Margaret> When someone is attacking all of my routers via their SSH
Margaret> ports, I do have a couple of options for blocking this at my
Margaret> firewall -- (1) block all inbound traffic from the attacker,
Margaret> (2) block all inbound SSH traffic to my routers, (3) block
Margaret> all inbound traffic of any kind to my internal routers. Any
Margaret> of these choices would (I think) block the attack while I
Margaret> removed the compromised user from all of my routers. Since
Margaret> I have to manage users on my routers when I get new
Margaret> employees, old ones leave, etc., this shouldn't be that
Margaret> horrible.
(1) may not be possible, depending on the type of attack (discussed already)
(2) will halt business in some case and certain make an awful lot of
mad users of the network..
(3) same as 2 but even worse.
(It's possible you're assuming the netconf traffic will only ever go
to backbone infrastructure and thus you could block access to *just*
your routers at the border and they're the only boxes that would be
affected. However, its unwise to assume this as most other protocols
have in the past outgrown their originally anticipated uses.
Certainly it'll be used to configure many types of devices).
Margaret> I understand your statements, and I will grant that you have
Margaret> far more security experience than I do. But, it isn't my
Margaret> understanding that people will want to block all external
Margaret> management access to their managed devices, since they will
Margaret> want the ability to manage them remotely.
I agree, some will. I think it's a huge mistake to think that
everyone does. I let snmpv3 across my controlled borders because I
trust the protocol (mostly) and the software I have installed.
However, I know a lot of other people that have it turned off at their
borders because they don't want remote access and don't trust the
protocol software they have deployed not to occasionally suffer from
buffer-overflow attacks. If SNMPv3 had gone over a standard port (say
snmpv3 tunneled through a ssh specific security model), it would be
impossible to take this security precaution. Note that blocking SNMP
at the border was specifically recommended by the CERT summary when
the famous SNMP bugs came around. What if suddenly the xml parsers
suddenly hit a similar problem when parsing large ints or strings?
You suddenly have no way to quickly protect the internal network from
attacks coming in over netconf/ssh.
--
"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/>