Re: Writable SNMP

[Christopher Morrow <morrowc.lists () gmail com>]

On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley
<keegan.holley () sungard com> wrote:
> 2011/12/6 Christopher Morrow <morrowc.lists () gmail com>
> > On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared () puck nether net>
> > wrote:
> > > On Dec 6, 2011, at 11:07 AM, Keegan Holley wrote:
> > >
> > > > For a few years now I been wondering why more networks do not use
> > > > writable
> > > > SNMP.  Most automation solutions actually script a login to the various
> > > > equipment.  This comes with extra code for different vendors, different
> > > > prompts and any quirk that the developer is aware of and constant
> > > > patches
> > > > as new ones come up.  Writable SNMP seems like an easier way to deal
> > > > with
> > > > scripted configuration changes as well as information gathering.
> > > > Admittedly, you will have to deal with proprietary mibs and reformat
> > > > the
> > > > data once it's returned.  Most people consider it insecure, but in
> > > > reality
> > > > it's no worse than any other management protocol.  Yes I know netconf
> > > > is
> > > > better, but in most circles I'd have problems explaining what netconf
> > > > is,
> > > > why it's better and that I'm not making it up.  So I'll take what I can
> > > > get.
> > >
> > > Some of the problems is the bulk nature of some config changes (or
> > > transactional
> > > nature on those that support atomic operations) have been harder to
> > > automate.
> > >
> > > Anyone that has spent any quantity of time with ASN.1 generally would
> > > agree.
> > >
> > > I recall some bay networks gear you could only program with the proper
> > > OID
> > > as the cli was basically a SNMP-SET operation on the device.
> >
> > yea... same with cascade devices... icky things (both bay and cascade!)
> >
> > > The errors/feedback tends to be very poor over SNMP as well as you may
> > > need
> > > to walk/revisit a large number of elements to make things happen
> > > properly.
> >
> > fun story/fact, you can send an snmp write to the broadcast address of
> > a network of NT (at least, probably also post-nt versions of the OS)
> > machines, and set their default-ttl to some arbitrary number. "Your
> > network is too chatty... not anymore! now your internet is 5 hops
> > across!"
>
>
> Let's leave the legacy boxes out of this.  Remember that SNMP bug that could
> keel over a cisco router?  I forget the details other than the guy who wrote
> c code at black hat to kill routers after cisco refused to patch.
> > > Have you had a good experience with using SNMP-Write?  I have not.
> >
> > long ago, in a network far away (not on the interwebs) we used snmp
> > write to trigger a tftp config load. It worked nicely... I'm fairly
> > certain I'd not do this on an internet connected network today though.
>
>
> I can see the other comments about interactive commands and bulk
> read/writes, but what's the harm of doing it on internet connected boxes vs.
> non-internet boxes.  Just about everyone uses snmp reads in the interwebs

I think the general feeling is that snmp is udp so it's spoofable and
your perimeter acls will never be 100% (or rather, are you willing to
risk them not being 100%?)

> and as such filters it at their edges and hopefully on each platform.  You'd
> secure it the same way you'd secure readable SNMP I assume.

read is 'painful', write can be downright deadly (to your SLAs).

> > Also, who tests snmp WRITE in their code? at scale? for daily
> > operations tasks?
>
>
> lol, that could be a problem.

yea, I bet the number of people that test, at scale/operations-pace,
snmp WRITE is countable on a single hand.

> > ... (didn't the snmp incident in 2002 teach us
> > something?)
> Please elaborate.

<http://www.cisco.com/warp/public/707/cisco-sa-20010227-ios-snmp-ilmi.shtml>

oh, 2001... memory lag :(