Home page logo
/

nanog logo nanog mailing list archives

Re: Writable SNMP
From: Christopher Morrow <morrowc.lists () gmail com>
Date: Wed, 7 Dec 2011 12:51:29 -0500

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]