Writable SNMP

Tue Dec 6 20:00:27 UTC 2011

On Tue, Dec 6, 2011 at 11:49 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
> 2011/12/6 Christopher Morrow <morrowc.lists at gmail.com>
>>
>> On Tue, Dec 6, 2011 at 11:16 AM, Jared Mauch <jared at 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 :(