http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
This one seems much worse than the TCP RST problem.
If you ever read SNMP specs, you can realize, that there is not any C or C++
SNMP implementation without such problem. So, rule number 1 is _never
expose SNMP to Internet, and be careful to filter out any inbound packets,
forwarded to your SNMP ports.
It is easy to predict next SNMP problem in next 6 month, etc... Too
complicated protocol, implemented by (in most cases) less qualified
engineers (SNMP module is always of low priority, in any project - I never
saw an exception, and Cisco is not one).
// In reality, it is not problem at all... except for some clueless
providers.
Which makes me wonder, why in most implementations services listen in
each configured address. Provider might have lot of link networks, even
from customers demand from his link network. This makes filtering in
borders little less feasible. And for this particular attack two
way comminication is not needed, so SNMP with ACL is not enought to
mitigate this. With explicitly defined listen addresses, filtering in border
would be easy.
JunOS allows to set interfaces to SNMP, but according to netstat it
still listens in *.161.