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