- NANOG - lists.nanog.org

nsi problems?
by Joseph McDonald 14 Feb '02

14 Feb '02

Can anyone do a whois against whois.crsnic.net? I can't seem to get to it. Also, I've been seeing lots of timeouts and unreachble *.gtld-servers.net, they keep blinking on an off, this has been going on for at least a few hours now. % traceroute to whois.crsnic.net (198.41.3.54), 64 hops max, 40 byte packets [...] 12 0.so-2-2-0.XL1.DCA8.ALTER.NET (146.188.177.237) 159.970 ms 155.945 ms 134.807 ms 13 POS6-0.GW1.DCA8.ALTER.NET (146.188.162.177) 187.366 ms 109.277 ms 98.351 ms 14 NSI-gw.customer.alter.net (65.195.225.154) 131.584 ms 135.006 ms 138.982 ms 15 * * * 16 * * * 17 * *^C dig @g.gtld-servers.net crsnic.net ; <<>> DiG 8.3 <<>> @g.gtld-servers.net crsnic.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend to server g.gtld-servers.net 192.42.93.30: Operation timed out thanks, -joe

2 2

Operational Impact of CA-2002-03 ?
by Frank B. Scalzo 14 Feb '02

14 Feb '02

Has anyone seen any discernable operational impact from CA-2002-03? Things like: increase in SNMP probes, increase in bgp churn due to outside networks being affected, customer complaints, increase in number of customer flaps, anyone willing to admit to being directly impacted, anyone willing to admit surviving an attempt, does anyone have any evidence of an actual exploit, any evidence that people wearing the wrong color hats are using this or trying to? Frank Scalzo

6 5

snmp-forum
by Sue Joiner 14 Feb '02

14 Feb '02

Forwarded for Ian Finlay by owner-nanog. Sorry for the slow turn around, I was flying back from Miami yesterday. -sue Sue Joiner Merit Network owner-nanog(a)merit.edu XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Date: Wed, 13 Feb 2002 12:56:11 -0500 (EST) From: Ian Finlay <iaf(a)cert.org> X-X-Sender: iaf(a)watson.blue.cert.org To: nanog(a)merit.edu Cc: cert(a)cert.org Subject: snmp-forum Message-ID: <Pine.LNX.4.44.0202131253250.8143-100000(a)watson.blue.cert.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nanog(a)merit.edu -----BEGIN PGP SIGNED MESSAGE----- As you may already know, the CERT/CC has set up a forum where administrators can share ideas and techniques that can be used to develop proper defenses. We have essentially created an unmoderated mailing list for system and network administrators to discuss helpful techniques and tools. You can subscribe to the mailing list by sending an email message to majordomo(a)cert.org. In the body of the message, type subscribe snmp-forum After you receive the confirmation message, follow the instructions in the message to complete the subscription process. This information was included in the Advisory we sent out yesterday (http://www.cert.org/advisories/CA-2002-03.html) Since that time, ~525 people have subscribed and the list continues to grow. I have included a digest of what has transpired on the list so far for your convenience. Because of the expertise that exists within the NANOG community, we'd love to have you folks participate (some of you are already). Thanks, Ian Ian A. Finlay CERT (R) Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA USA 15213-3890 - ----------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:33 PM -0500 From: Joshua Wright <jwright(a)jwu.edu> To: "'snmp-forum(a)cert.org'" <snmp-forum(a)cert.org> Subject: RE: Bypassing Cisco ACL's for SNMP <me backpedaling> Reading Cisco's advisory another few times, it seems the configuration in question that will bypass ACLs goes like this: access-list 1 permit host X.X.X.X access-list 1 deny any log snmp-server community blah rw 1 snmp-server host X.X.X.X blah When setting the trap host for SNMP with the same community string, access to the SNMP will be permitted with no access to the MIB (bypassing the ACL). This is because of the order the configuration commands are kept in the configuration file, the "snmp-server host" command happens _after_ the "snmp-server community" command. According to the Cisco advisory, even without access the MIB, the PROTOS tool has the ability to DoS the router. You can configure the router in this fashion: access-list 1 permit host X.X.X.X access-list 1 deny any log snmp-server host X.X.X.X blah snmp-server community blah rw 1 And your ACL will be applied, but a reboot will revert to the same order as described above. Best to use different community strings for GET/SET and traps. Better yet, use a different pair of community string for each router you control. Better still, filter UDP/161 and UDP/162 at your edge, then apply the steps described in the Cisco advisory. </me backpedaling> The question remains however - why does IOS accept SNMP GET/SET PDUs on a community string defined for traps, even without access to the MIB? Why not just reject these packets as if we didn't have "snmp-server community string" defined? I consider this a separate bug aside from the PROTOS exploit. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University Joshua.Wright(a)jwu.edu pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - -----Original Message----- From: snmp-forum(a)cert.dfn.de [mailto:snmp-forum@cert.dfn.de] Sent: Wednesday, February 13, 2002 9:01 AM To: snmp-forum(a)cert.org Subject: Bypassing Cisco ACL's for SNMP - - -----BEGIN PGP SIGNED MESSAGE----- Joshua Wright writes: > Trying to confirm or deny posting on securitydatabase.net that indicates "If > there is a snmp-communitystring defined with an ACL on it and a 'snmp-server > host' is configured with the same community-string, then a packet could be > send to the router/switch, that ignores all ACL's on the device". The > posting is possibly suspect to misinterpretation of the CERT advisory, but > otherwise scary if confirmed. Not really. This is basically a configuration error. Imagine the following configuration: access-list 1 permit host X.X.X.X access-list 1 deny any snmp-server community blah rw 1 snmp-server community blah rw So what the 3rd line says is: Allow SNMP PDUs but only from ip address X.X.X.X (depending on the definition of access-list 1) and only when the community is equal to "blah". Then the 4th line says: Allow all SNMP PDUs as long as the community string is equal to "blah". What we really have are two conflicting statements and the cisco device just obeys the last order given. These are only to options of the same statement, none of them is "superior" to the other. Really, this is IMHO just a plain dumb way to configure SNMP on ciscos. > Certainly, UDP ACL's can be bypassed easily through spoofing the > source address of the packet, but this requires knowledge of the > permit statements in the ACL as well as the community string for > access. The only safe way, as long as fixed IOS versions are not widely deployed, is to have a seperate management VPN (with IPSec on it) or to manage the routers only through SSH. Both may not be present on some devices. Of course, the canonical way would be to ditch SNMPv1 and switch to SNMPv3 with signing and encryption turned on. But that is diffucult, because a) SNMPv2 and SNMPv3 are not supported by most SNMP manager software. b) I'm not sure about the performance impact on the managers side when dealing with a lot of devices. c) I'm not sure about the performance impact on the agents side when dealing with a lot of requests in a short time. Regards, Klaus Moeller, DFN-CERT - - - -- Klaus Moeller | mailto:moeller@cert.dfn.de DFN-CERT GmbH | http://www.cert.dfn.de/team/moeller/ Oberstrasse 14b | Phone: +49(40)808077-555 D-20144 Hamburg | FAX: +49(40)808077-556 Germany | PGP-Key: finger moeller(a)ftp.cert.dfn.de - - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface iQEVAwUBPGpxbYrEggYLt8j5AQFYIAf5AcIIsrEUGSraka5ZmG9cwhJtxzAq3T8e CTa2YnqrGhBDWdn68NG4ivqJJqweQ5FraK/0WlWBKXwjmrd5oWFP5AHt0L0MhaBL 8tC45njL6sVlG7d8gb1+/Z/3VmsbBOX9c3++veuDCuHuaq2071sraWFQuxglPIng TAEc+jAHBo+UAj9Zs8GXA1HJs3DWrOg9tO9u9aHtesXh8Mcj78jH9ycafszIzGU7 0s/N0CBXWtiUeZ/qLx0YzcmGj4KHfuXMjmh4rQlsG5pD70PEkCwBtp5v361pCjky NyK2MeW2uUs2WZLKNSGUGau7VtZT0ZugS4R9rwcZe/oCA58bCielLw== =zFlB - - -----END PGP SIGNATURE----- - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:16 PM -0500 From: Joshua Wright <jwright(a)jwu.edu> To: snmp-forum(a)cert.org Subject: RE: Cisco SNMP Recommendations? This is good practice, but does not protect you from the Cisco "surprise" community strings (cable-docsis, ILMI) that have been uncovered in IOS. Surely, others exist. Best to block SNMP at your firewall or border router before it enters your network. Also apply the controls you have documented below for a multi-tiered approach. Also, I am a fan of adding "access-list 10 deny any log" to ACL's to gather some logging information. This makes numbered access-lists difficult to maintain when adding additional hosts to be permitted because you have to perform a "no access-list 10" and recreate the entire ACL to add another permitted host/network. My 2 cents. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University Joshua.Wright(a)jwu.edu pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - -----Original Message----- From: Ryan J Standish [mailto:rjs9@lurch.cit.buffalo.edu] Sent: Wednesday, February 13, 2002 11:50 AM To: Jim Duncan Cc: Robert.Osantowski(a)infoUSA.com; snmp-forum(a)cert.org Subject: Re: Cisco SNMP Recommendations? Any opinions/ideas? If protecting the router itself is the only concern, does the following acls offer any less protection than applying an explicit acl to an interface instead of just to the snmp-server config? Is the rtr still vulnerable to an snmp DOS attack? access-list 10 remark -- SNMP Read Access -- access-list 10 permit 192.168.100.0 0.0.0.255 access-list 11 remark -- SNMP Write and Telnet Access -- access-list 11 permit 192.168.100.0 0.0.0.255 snmp-server community foobar RO 10 snmp-server community foobar2 RW 11 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:16 PM -0500 From: Jim Duncan <jnduncan(a)cisco.com> To: snmp-forum(a)cert.org Subject: port 1993 is a shill Folks, I can't find the previous message, but earlier today someone in this forum asked about filtering port 1993 in regard to the current SNMP vulnerabilities. We don't use port 1993, tcp or udp, in any Cisco products. There is no reason to call special attention to it. Port 1993 is an artifact from a moribund project many years ago that provided network management over TCP using a system based on SNMP. I believe the effort predates any 11.0 releases of IOS. I could find no 11.x or 12.x releases that provided services for port 1993, tcp or udp. Filtering unnecessary ports and turning off unneeded services is always a good idea, but there is nothing especially important about 1993. We have mentioned this in our advisory and ask that unless you have specific reasons to include it, please remove it from your own notices. It generates a lot of unnecessary calls and messages. If you _do_ have a good reason to mention it, please let us know. :-) Thanks. Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: jnduncan(a)cisco.com Phone(Direct/FAX): +1 919 392 6209 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:10 PM -0500 From: Joshua Wright <jwright(a)jwu.edu> To: "'snmp-forum(a)cert.org'" <snmp-forum(a)cert.org> Subject: RE: Cisco SNMP Recommendations? I would modify your ACL slightly to add logging information for attempts to access SNMP resources: ip access-list extended example1 deny udp any any eq snmp log-input deny udp any any eq snmptrap log-input permit ip any any If you are not already, start logging to a syslog server as well: logging facility local0 logging trap debug logging 1.1.1.1 On your Unix box, something like $ echo "local0.debug /var/log/routerlogs.log" >>/etc/syslog.conf $ kill -HUP pid_of_syslogd They you will have some logging information regarding whether you have broken something legitimate, or if someone is trying to access SNMP illegitimately. You can also check out "sh logging" if you are "logging buffered nnn". SANS also recommended blocking UDP/1993, but only if your IOS was born in the stone ages (e.g. <11.0). If your IOS is <11.0 you have other issues to worry about. :) - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University Joshua.Wright(a)jwu.edu pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - -----Original Message----- From: Jim Duncan [mailto:jnduncan@cisco.com] Sent: Wednesday, February 13, 2002 11:29 AM To: Robert.Osantowski(a)infoUSA.com Cc: snmp-forum(a)cert.org Subject: Re: Cisco SNMP Recommendations? Robert Osantowski writes: > Could anyone offer their suggestions for blocking SNMP requests at a network > boundary on a Cisco Router? > > I could place an ACL on the inbound Internet interface and do something like > I've shown below, but I'm wondering if there is a better way? > > Interface Serial0/0 > ip access-group example1 in > > ip access-list extended example1 > deny udp any any eq snmp > deny udp any any eq snmptrap > permit ip any any > > Any feedback would be appreciated. Thanks. Rob, this is the same thing we recommend in our advisory, http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: jnduncan(a)cisco.com Phone(Direct/FAX): +1 919 392 6209 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 11:49 AM -0500 From: Ryan J Standish <rjs9(a)lurch.cit.buffalo.edu> To: Jim Duncan <jnduncan(a)cisco.com> Subject: Re: Cisco SNMP Recommendations? Any opinions/ideas? If protecting the router itself is the only concern, does the following acls offer any less protection than applying an explicit acl to an interface instead of just to the snmp-server config? Is the rtr still vulnerable to an snmp DOS attack? access-list 10 remark -- SNMP Read Access -- access-list 10 permit 192.168.100.0 0.0.0.255 access-list 11 remark -- SNMP Write and Telnet Access -- access-list 11 permit 192.168.100.0 0.0.0.255 snmp-server community foobar RO 10 snmp-server community foobar2 RW 11 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 11:28 AM -0500 From: Jim Duncan <jnduncan(a)cisco.com> To: Robert.Osantowski(a)infoUSA.com Subject: Re: Cisco SNMP Recommendations? Robert Osantowski writes: > Could anyone offer their suggestions for blocking SNMP requests at a network > boundary on a Cisco Router? > > I could place an ACL on the inbound Internet interface and do something like > I've shown below, but I'm wondering if there is a better way? > > Interface Serial0/0 > ip access-group example1 in > > ip access-list extended example1 > deny udp any any eq snmp > deny udp any any eq snmptrap > permit ip any any > > Any feedback would be appreciated. Thanks. Rob, this is the same thing we recommend in our advisory, http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: jnduncan(a)cisco.com Phone(Direct/FAX): +1 919 392 6209 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 10:22 AM -0600 From: Robert.Osantowski(a)infoUSA.com To: snmp-forum(a)cert.org Subject: Cisco SNMP Recommendations? Could anyone offer their suggestions for blocking SNMP requests at a network boundary on a Cisco Router? I could place an ACL on the inbound Internet interface and do something like I've shown below, but I'm wondering if there is a better way? Interface Serial0/0 ip access-group example1 in ip access-list extended example1 deny udp any any eq snmp deny udp any any eq snmptrap permit ip any any Any feedback would be appreciated. Thanks. - - -Rob Osantowski - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 4:30 PM +0100 From: snmp-forum(a)cert.dfn.de To: snmp-forum(a)cert.org Subject: Bypassing ACL's to DoS Cisco routers through OOB SNMP GET's Joshua Wright writes: > And goes on to mention that the PROTOS tool may be able to DoS a router that > has no access to the MIB through the use of the community string used to > SEND trap information. As far as I understand this: As long as the SNMP Server is enabled (although no communities are defined), the cisco does evaluate SNMP PDUs. If the error is triggered *before* the community string is evaluated (for example, when evaluating the structure of the PDU or the version number), the "protection" from the community string is bypassed. > I do not understand what extra protection is gained from having a different > community string for access to the MIB and for sending SNMP traps. I > believe this is a good common practice, and using ACL's to control access to > the router is an otherwise good idea as well. Unless someone is sniffing > the segment that the SNMPv1 messages are sent out on, what is the ultimate > risk of having the community string the same for MIB access and for traps? > Has the PROTOS tool uncovered a spot in the MIB where the community string > is kept? This only works, if the traps take a different way from the router to the manager than the requests take from the manager to the router. If, in this case, the community in the trap PDU is the same as for request PDUs, the cisco would be compromised. Second: Traps may be triggered from the outside, even if the attacker has no way to access the device through the "management channel". So, the attacker could trigger and sniff a trap anytime he/she wants, while requests from the manager may be send only a few times a day. But I agree on the basic point, it's pretty useless if the attacker can sniff both traps and requests. Regards, Klaus Moeller, DFN-CERT - - -- Klaus Moeller | mailto:moeller@cert.dfn.de DFN-CERT GmbH | http://www.cert.dfn.de/team/moeller/ Oberstrasse 14b | Phone: +49(40)808077-555 D-20144 Hamburg | FAX: +49(40)808077-556 Germany | PGP-Key: finger moeller(a)ftp.cert.dfn.de - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 3:00 PM +0100 From: snmp-forum(a)cert.dfn.de To: snmp-forum(a)cert.org Subject: Bypassing Cisco ACL's for SNMP - - -----BEGIN PGP SIGNED MESSAGE----- Joshua Wright writes: > Trying to confirm or deny posting on securitydatabase.net that indicates "If > there is a snmp-communitystring defined with an ACL on it and a 'snmp-server > host' is configured with the same community-string, then a packet could be > send to the router/switch, that ignores all ACL's on the device". The > posting is possibly suspect to misinterpretation of the CERT advisory, but > otherwise scary if confirmed. Not really. This is basically a configuration error. Imagine the following configuration: access-list 1 permit host X.X.X.X access-list 1 deny any snmp-server community blah rw 1 snmp-server community blah rw So what the 3rd line says is: Allow SNMP PDUs but only from ip address X.X.X.X (depending on the definition of access-list 1) and only when the community is equal to "blah". Then the 4th line says: Allow all SNMP PDUs as long as the community string is equal to "blah". What we really have are two conflicting statements and the cisco device just obeys the last order given. These are only to options of the same statement, none of them is "superior" to the other. Really, this is IMHO just a plain dumb way to configure SNMP on ciscos. > Certainly, UDP ACL's can be bypassed easily through spoofing the > source address of the packet, but this requires knowledge of the > permit statements in the ACL as well as the community string for > access. The only safe way, as long as fixed IOS versions are not widely deployed, is to have a seperate management VPN (with IPSec on it) or to manage the routers only through SSH. Both may not be present on some devices. Of course, the canonical way would be to ditch SNMPv1 and switch to SNMPv3 with signing and encryption turned on. But that is diffucult, because a) SNMPv2 and SNMPv3 are not supported by most SNMP manager software. b) I'm not sure about the performance impact on the managers side when dealing with a lot of devices. c) I'm not sure about the performance impact on the agents side when dealing with a lot of requests in a short time. Regards, Klaus Moeller, DFN-CERT - - - -- Klaus Moeller | mailto:moeller@cert.dfn.de DFN-CERT GmbH | http://www.cert.dfn.de/team/moeller/ Oberstrasse 14b | Phone: +49(40)808077-555 D-20144 Hamburg | FAX: +49(40)808077-556 Germany | PGP-Key: finger moeller(a)ftp.cert.dfn.de - - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface iQEVAwUBPGpxbYrEggYLt8j5AQFYIAf5AcIIsrEUGSraka5ZmG9cwhJtxzAq3T8e CTa2YnqrGhBDWdn68NG4ivqJJqweQ5FraK/0WlWBKXwjmrd5oWFP5AHt0L0MhaBL 8tC45njL6sVlG7d8gb1+/Z/3VmsbBOX9c3++veuDCuHuaq2071sraWFQuxglPIng TAEc+jAHBo+UAj9Zs8GXA1HJs3DWrOg9tO9u9aHtesXh8Mcj78jH9ycafszIzGU7 0s/N0CBXWtiUeZ/qLx0YzcmGj4KHfuXMjmh4rQlsG5pD70PEkCwBtp5v361pCjky NyK2MeW2uUs2WZLKNSGUGau7VtZT0ZugS4R9rwcZe/oCA58bCielLw== =zFlB - - -----END PGP SIGNATURE----- - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 8:16 AM -0500 From: Joshua Wright <jwright(a)jwu.edu> To: "'snmp-forum(a)cert.org'" <snmp-forum(a)cert.org> Subject: Bypassing Cisco ACL's for SNMP Trying to confirm or deny posting on securitydatabase.net that indicates "If there is a snmp-communitystring defined with an ACL on it and a 'snmp-server host' is configured with the same community-string, then a packet could be send to the router/switch, that ignores all ACL's on the device". The posting is possibly suspect to misinterpretation of the CERT advisory, but otherwise scary if confirmed. Certainly, UDP ACL's can be bypassed easily through spoofing the source address of the packet, but this requires knowledge of the permit statements in the ACL as well as the community string for access. Can anyone provide any additional information regarding this claim? Cisco did not provide any indication in their security advisory that this is true. Thanks. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University Joshua.Wright(a)jwu.edu pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 7:56 AM -0500 From: Joshua Wright <jwright(a)jwu.edu> To: "'snmp-forum(a)cert.org'" <snmp-forum(a)cert.org> Subject: Bypassing ACL's to DoS Cisco routers through OOB SNMP GET's Cisco has posted a security advisory regarding malformed SNMP message-handling vulnerabilities at http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml. In their advisory, Cisco identifies a workaround that involves using an ACL to control access to the SNMP MIB on the router. The advisory continues with a caveat that mentions: "If community strings are also configured for notifications, they must be different than the community strings used for requests in order for this workaround to be effective." And goes on to mention that the PROTOS tool may be able to DoS a router that has no access to the MIB through the use of the community string used to SEND trap information. I do not understand what extra protection is gained from having a different community string for access to the MIB and for sending SNMP traps. I believe this is a good common practice, and using ACL's to control access to the router is an otherwise good idea as well. Unless someone is sniffing the segment that the SNMPv1 messages are sent out on, what is the ultimate risk of having the community string the same for MIB access and for traps? Has the PROTOS tool uncovered a spot in the MIB where the community string is kept? Any other comments on the functionality of the PROTOS tool are welcome as well. Thanks. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University Joshua.Wright(a)jwu.edu pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 3:16 AM -0800 From: Noah Leaman <nleaman(a)apple.com> To: SNMP-Forum <snmp-forum(a)cert.org> Subject: HP OpenView and the SNMP problems How about people using HP OpenView products (e.g. Network Node Manager)... any tips to help secure oneself from this SNMP issue? - - -- Noah - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 10:50 AM +0000 From: "Clay, James" <James.Clay(a)bskyb.com> To: "'snmp-forum(a)cert.org'" <snmp-forum(a)cert.org> Subject: HPUX and the SNMP problems Hello, Has anyone got any more details/experience with the SNMP problem for MC/ServiceGuard and EMS for HPUX? Thanks, Jim ********************************************************************** Information in this email is confidential and may be privileged. It is intended for the addressee only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its contents to anyone. Thank you for your co-operation. ********************************************************************** - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 11:11 AM +0100 From: Livens Wim <WLivens(a)colt-telecom.be> To: "'snmp-forum(a)cert.org'" <snmp-forum(a)cert.org> Subject: nmap scan Does anyone has a reliable way of scanning large address ranges for open udp snmp ports ? I tried nmap -v -sU -p161,162,199,391,1993 but this gives false positives if the packets are dropped by packet filters (ACLs on routers) The manpage seems to confirm this: The technique is to send 0 byte udp packets to each port on the target machine. If we receive an ICMP port unreachable message, then the port is closed. Otherwise we assume it is open. Since an ACL just drops the packet, nmap assumes the port is open. - - -- Wim Livens. - - ---------- End Forwarded Message ---------- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBPGqny6CVPMXQI2HJAQFWtAP+LxMWaj66sdbHADBm5tyYjsvAgxgqpu7c SNfL8k7swFE9EAh3AgI1Pwyq9qoaUsowSsmqn0EtV5HVC4XCNzvUZiXk1RL+dZls 3dg//YQS7hxHkciXCIOcJFV50VrO6KRC8s+0KsJiif44fiSbJhCnpfhwDVFEj+Co L8oMxGirxfw= =WYTP -----END PGP SIGNATURE-----

1 0

Re: it's here
by Eric Brandwine 14 Feb '02

14 Feb '02

>>>>> "sd" == Sean Donelan <sean(a)donelan.com> writes: sd> On Tue, 12 Feb 2002, Alex Rubenstein wrote: >> http://www.cert.org/advisories/CA-2002-03.html sd> ASN.1 is pretty cool, but I've been wondering are there that sd> many ISPs which allow external SNMP access to their equipment? 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. ericb -- Eric Brandwine | To assert that the earth revolves around the sun is as UUNetwork Security | erroneous as to claim that Jesus was not born of a ericb(a)uu.net | virgin. +1 703 886 6038 | - Cardinal Bellarmine (during the Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

7 7

RE: it's here
by Jon Stanley 14 Feb '02

14 Feb '02

Hmm - who said they had to be physically separate? Being a layer 2 centric network has allowed us to extend device management functionality to not only the core, but also straight out to the edge CPE equipment - every piece of (non-legacy) CPE that we have has a 1918 address on it that the customer cannot see. The only incremental cost is the management of the management network - almost minimal, as the IP tracking scheme that we have extends nicely into the /32 range. There is also the required bandwidth, and the need for additional PVC's to the customer prem (these are 64k UBR PVC's) - again, minimal when you own the layer 2 network. Just my 2 cents. PS - these views are my own and do not necessarily represent those of my employer. -----Original Message----- From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] Sent: Wednesday, February 13, 2002 10:56 AM To: jerry scharf Cc: nanog(a)merit.edu Subject: Re: it's here sites) spanning multiple states or countries. Not everyone can afford to build both a backbone and a separate management WAN. Putting management in 1918 space is ok at one location, but gets tricky on a large network. Do we then also buy/maintain VPN hardware to connect all the various 1918 management networks to the NOC?

1 0

Summary: Nothing to report
by Sean Donelan 14 Feb '02

14 Feb '02

I came home to a deluge of e-mail. Whatever happened, I missed it at 30,000 feet. Here is what I found. AT&T Worldnet: E-mail and certificate problems (just ignore the warning) C&W: Green across the board Earthlink/Mindspring: Dialup authentication problems (San Jose and other locations) Genuity: Normal Sprint: A couple of router hardware problems (Tacoma and Washington DC) UUNET: No outages

1 0

NANOG Help Desk???
by Bill Thompson 14 Feb '02

14 Feb '02

I just gotta rant about this. When the Hell did the NANOG list become a help desk? Why are we encouraging theses questions about configuring a Linux box to be a router and how to get Cisco IOS to make coffee? I thought that this list was for OPERATIONAL content and not to answer HOW TO questions about home networks. There are other lists for that. I have configuration questions too, but that's what Google is for, not NANOG. I would like to propose that people DO NOT reply to these posts, or if they want to help take it off list. -- BillT(a)Mahagonny.com - PGP KeyID#: 0xFB966670 "Crappy old OSes have value in the basically negative sense that changing to new ones makes us wish we'd never been born." -Neal Stephenson 1999

3 2

Fibre cut in the DC area
by Thomas Kernen 13 Feb '02

13 Feb '02

Don't have much details to provide (yet) but I understand that there is a major fibre cut in the DC area that is affecting multiple carriers. Thomas

1 1

Re: it's here
by Eric Brandwine 13 Feb '02

13 Feb '02

>>>>> "js" == Jesper Skriver <jesper(a)skriver.dk> writes: js> On Wed, Feb 13, 2002 at 03:55:25PM +0000, Eric Brandwine wrote: >> Without control plane seperation (and it's not possible with Cisco, >> Juniper, or most other routers out there), management services are >> listening on the public network, and that makes this very scary, >> regardless of filtering policies, etc. js> interfaces { ... js> } js> firewall { ... js> } OK, but that's filtering. The telnet/ssh/snmp daemon is still listening on all interfaces. You can't get there, as long as your filter stands, but those are some hard filters to write. They're simple when they're simple, but they're very complex when they're not. You're relying on your filters, rather than on proper configuration of the daemon. On a UNIX system, you can bind a service to all interfaces (e.g. *.161) or just to a specific interface (10.1.2.3:161). This should be possible in general, on all routers. We HAVE an OOB management network. This is where all our console servers, switches (there is no Ethernet in the backbone, don't shove VLANs at me), etc all live. This address space is not routed to you. We like this. There's no cost issues, we've already paid for it, and need it for our layer 1/2 network anyway. But then you plug an IP port on the router (vs. a console port) into the mgmt net, and you've bridged the public net and the mgmt net. Virtual routers are capable of maintaining multiple routing tables, but last I checked, Juniper was not. So how do you route this? I send an SNMP query to the device. It comes in over the mgmt net (because for me, in my datacenter, the loopback for that device (or it's mgmt IP) is routed across the mgmt net). The device recieves, digests, and decides to respond to this query. Where does it send it? My datacenter is routed on the internet, so does it send it out the public interface? Or do I route my datacenter over the mgmt net? You can start filtering, but then those filters are suddenly very important, crucial to the proper operation of the network. Better not fat finger anything. Ever. Or do I move all my backbone facing datacenters into a network that is not routed on the Internet, but only on the mgmt net? That has it's own host of problems. And you still have to convince the router not to propagate routes that it learns from the mgmt net into the public network. This can be done with filters, but when you have a global mgmt network spread over many netblocks, regions, etc, it's ugly. The router needs to act as a router to the public network. But it needs to act as a host (with only 1 interface) to the mgmt net. This is not how current routers work. Been there, done that, it's not that simple. ericb -- Eric Brandwine | Put your hand on a hot stove for a minute and it seems UUNetwork Security | like an hour, sit next to a pretty woman for and hour ericb(a)uu.net | and it seems like a minute. That's relativity. +1 703 886 6038 | - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

3 2

Re: it's here
by Eric Brandwine 13 Feb '02

13 Feb '02

>>>>> "rds" == Ron da Silva <ron(a)aol.net> writes: >> >> http://www.cert.org/advisories/CA-2002-03.html >> sd> ASN.1 is pretty cool, but I've been wondering are there that sd> many ISPs which allow external SNMP access to their equipment? 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. rds> But it should be not only feasible, but standard practice. It's impossible using most high bandwidth gear that's out there. At these speeds, you can either route the bits, or look at them, but not both. Juniper is the one vendor that's given us packet inspection abilities that scale with bandwidth. We have non-Juniper routers. Please, tell your vendors you want line-rate filtering up to layer 4. We're tired of being told "But you're the only ones that ask for this". Without control plane seperation (and it's not possible with Cisco, Juniper, or most other routers out there), management services are listening on the public network, and that makes this very scary, regardless of filtering policies, etc. ericb -- Eric Brandwine | "Intel Inside" is a Government Warning requied by Law. UUNetwork Security | ericb(a)uu.net | +1 703 886 6038 | - Usenet Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

9 8