http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml This one seems much worse than the TCP RST problem. -- Mikael Abrahamsson email: swmike@swm.pp.se
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. ----- Original Message ----- From: "Mikael Abrahamsson" <swmike@swm.pp.se> To: <nanog@merit.edu> Sent: Wednesday, April 21, 2004 2:40 AM Subject: snmp vuln
http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
This one seems much worse than the TCP RST problem.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On (2004-04-21 23:24 -0700), Alexei Roudnev wrote:
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.
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. -- ++ytti
participants (3)
-
Alexei Roudnev -
Mikael Abrahamsson -
Saku Ytti