The PROTOS group also tested HTTP, WAP, and LDAP in addition to SNMP. They also have a paper on constructive disclosure wherein they outline the need to a black-box test suite for use by customers and vendors to ensure simple buffer overflows, format string errors, etc. are easier to find. So, they are essentially attempting to empower the consumer and the vendor to prevent these types of programming errors by releasing a test suite to test for these things. See this paper for more information: http://www.ee.oulu.fi/research/ouspg/protos/sota/FIRST2001-disclosures/paper... On 12-Feb-2002, Sean Donelan wrote:
On 12 Feb 2002, Eric Brandwine wrote:
sd> SNMP is a UDP management protocol, and even under the best of sd> conditions, accepting packets from out of the blue isn't a good sd> idea.
Spoofed packets?
It's not feasible to filter antispoof at OC-12 or OC-48 line rate on all customer facing interfaces.
I can remember many cases when my HP Openview network discovery process would attempt to map the entire Internet because it strayed into a peers network. So it may fairly common.
At least one provider has told me they don't use in-band management for their network infrastructure. They have a completely seperate frame network connecting to POP management LANs which in turn is connected to seperate management ports on the equipment. I don't know how common this is among large providers.
I had a smaller network, so I filtered the IP block used for my management LAN from all external sources (and "logged" the ACL's so I picked up the stray packets from places I missed). A "real" packet should never be sourced from outside my network topology, so even if you spoofed the IP address the topology would block it. Of course, this depended on topological integrity. I can understand if larger providers why large can't do that, it doesn't scale.
But there are a lot of small and medium providers that can do it.
I agree, its a glass house issue. I was just wondering how bad of an issue it really is.