Re: Writable SNMP

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

On Wed, Dec 7, 2011 at 11:29 AM, Keegan Holley
<keegan.holley () sungard com> wrote:
> > > 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%?)
>
>
> That's a given even though there's still the string to deny the spoofed
> traffic someone could cause a fair amount of trouble if they knew what your

so... be cautious here, the 'acl' on the community string is really
'who can use this string' you have to still process the packet to some
extent before you decide that the string doesn't match NMS1's ip
address :(

you need also to traffic filter (in Cisco CoPP, in Juniper
LoopbackFilter)... that said, someone can bomb your loopback with
'public' and just spoof the src to your NMS, or your NOC or ... all
easy to figure out :( (well the noc is at least :) ).

> acl's look like.  That being said I don't think I've ever seen a company
> that doesn't at least use SNMP for billing and basic monitoring and many
> don't think to block it at their edge.  It's hard to convince someone to

yea, RO though, at least... though still, you process the packets to
see 'oh yea, not my string' :(

> change something that's been around for years though.  SNMP is flawed though
> and enabling writes just makes it worse.

yes.

> > > 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 :(
>
>
> I don't remember hearing about this causing issues in a production network.

There were lots of people with things changing on their devices
without their knowledge :(

>  According to the article you can just filter SNMP by IP which should be in
> place anyway.  It's triggered by some sort of hidden string which would make
> it malicious, unless I'm missing something.

yep, just 'hey there's a hidden community string, which isn't supposed
to actually be available outside the local box, and is RW... whoops!
the intern made it available :('

coupled with the fact that 90% of the industry had the same roots for
snmp code;(

> In lieu of a software upgrade, a workaround can be applied to certain IOS
> releases by disabling the ILMI community or "*ilmi" view and applying an
> access list to prevent unauthorized access to SNMP. Any affected system,
> regardless of software release, may be protected by filtering SNMP traffic
> at a network perimeter or on individual devices.

right, but as I said above, the community-string restrictions don't
help you in cases where you haven't filtered source-addresses in
loopback/copp :( people still get to grind on your router's snmp
process, maybe there's another way in, maybe there's a bug in the
snmpd :(

-chris