- Test - lists.nanog.org

zebra/ospf issue
by Josh Gentry 17 Feb '02

17 Feb '02

Folks, I'm experimenting with using Zebra running on a Debian box to do OSPF with the Ciscos on our network. The zebra box has 2 interfaces, each in a different area. This is the first time we have tried to impliment multiple areas on our network. Right now, area 51 consists only of the zebra box and a Cisco 2500, and is just for testing. The zebra box is forming a full adjacency with the Cisco in area 51 with no problems. It will not, however, become fully adjacent with the DR and BDR in area 0. This seems to be preventing the distrobution of routes to the zebra box. Distrobution of routes in area 51 works fine. Here is my config, minus auth info. ! Zebra configuration saved from vty ! 2002/02/02 16:35:11 ! hostname ospfd log file /var/log/zebra/ospfd.log service password-encryption ! ! interface lo ! interface eth1 ip ospf authentication-key <password> ! interface eth0 ip ospf message-digest-key <keyid> md5 <password> ip ospf priority 5 ip ospf hello-interval 10 ip ospf dead-interval 40 ! router ospf ospf router-id 216.184.8.55 ospf abr-type cisco ospf rfc1583compatibility network 198.59.115.0/24 area 0 network 216.184.8.0/24 area 51 area 0 authentication message-digest area 51 authentication redistribute static Any insight would be appreciated. Thanks. Josh jgentry(a)systemstability.org

3 5

AT&T 24.126.0.0
by Simon Higgs 17 Feb '02

17 Feb '02

Hi, Can someone confirm that there's some kind of DOS happening on the 24.126.0.0 network? I'm receiving an http request every three minutes (24/7) and it's been going on for about a week now. What is puzzling me is that each request is coming from what appears to be a random address within this same net block. If anyone from AT&T is out there that knows what this is please contact me. Best Regards, Simon -- ###

1 0

Re: zebra/ospf issue
by Josh Gentry 17 Feb '02

17 Feb '02

> Folks, > > I'm experimenting with using Zebra running on a Debian box to do OSPF with > the Ciscos on our network. The zebra box has 2 interfaces, each in a > different area. This is the first time we have tried to impliment > multiple areas on our network. Right now, area 51 consists only of the > zebra box and a Cisco 2500, and is just for testing. > > The zebra box is forming a full adjacency with the Cisco in area 51 with > no problems. It will not, however, become fully adjacent with the DR and > BDR in area 0. This seems to be preventing the distrobution of routes to > the zebra box. The adjacency issue is solved. We were hoping to use the Debian Zebra package because we like their package management so much, but they do tend to be behind the development curve. When we built Zebra from the current source the adjacency issue just went away. Next question. Now that the adjacency issue is solved, the router that is in both area 51 and area 0 is learning routes from area 0, and the other router in area 51 is then learning those routes in turn. If I add a route on the area 51 only router, however, that route shows up on the router in both area 51 and area 0, but does not show up on the other routers in area 0. I am using all the redistrute commands I can find. I'm baffled at this point. Any insight would be appreciated. > > Distrobution of routes in area 51 works fine. > > Here is my config, minus auth info. > > ! Zebra configuration saved from vty > ! 2002/02/02 16:35:11 > ! > hostname ospfd > log file /var/log/zebra/ospfd.log > service password-encryption > ! > ! > interface lo > ! > interface eth1 > ip ospf authentication-key <password> > ! > interface eth0 > ip ospf message-digest-key <keyid> md5 <password> > ip ospf priority 5 > ip ospf hello-interval 10 > ip ospf dead-interval 40 > > ! > router ospf > ospf router-id 216.184.8.55 > ospf abr-type cisco > ospf rfc1583compatibility > network 198.59.115.0/24 area 0 > network 216.184.8.0/24 area 51 > area 0 authentication message-digest > area 51 authentication > redistribute static > Josh jgentry(a)swcp.com

1 1

NSI/VeriSign propogating incorrect DNS glue records
by David Luyer 16 Feb '02

16 Feb '02

Does anyone know any way to contact NSI and get them to remove or correct bogus glue records (host entries)? Not the phone number on their website for international callers - they're completely _not_ helpful. Very polite, just no help. Their automated systems send confirmation requests to the wrong addresses (the legacy contact address on the *-HST record rather than the new contact address on the domain, despite the claims on their help pages). As NSI are poisoning the DNS with incorrect and extraneous glue records, all domains with the DNS servers in question are broken, despite the domain which contains the DNS servers being already redelegated and having correct updated entries for those hostnames in it. I've called NSI twice but they just seem to make up random stories and tell me things I've done before aren't possible (pointing two registered nameserver names at one IP for example... we have a number pointing at one IP already, which they eventually verified). And sitting on hold to the USA is frustrating, too. Emailing them resulted in an automated response promising an answer within 24 hours. 36 hours ago. Can another registrar even do anything? Since NSI have the domain and host record, it doesn't seem likely. And this is really urgent for me since the bogus/old IPs being propogated by NSI are to be derouted in less than 48 hours, so even if they do fix it there's still outage time for the domains due to the 48 hour TTL. It's just completely screwed up that they can't even verify and expedite the request in any way and just make up excuses like "our mail server is playing up" and "email tends to take 24-48 hours to get through". I don't have a problem getting email from/to anyone else on the internet in less than a minute... David.

3 3

The Cidr Report
by CIDR Report 16 Feb '02

16 Feb '02

This is an auto-generated mail on Fri Feb 15 23:00:00 PST 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 15Feb02 0) General Status Table History ------------- Date Prefixes 080202 105598 090202 105704 100202 105732 110202 105576 120202 105729 130202 105810 140202 105555 150202 105693 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 96.0.0.0/20 from AS3549 AS Summary ---------- Number of ASes in routing system: 12420 Number of ASes announcing only one prefix: 7568 (4308 cidr, 3260 classful) Largest number of cidr routes: 722 announced by AS701 Largest number of classful routes: 1371 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1152 889 263 22.8% Telstra Pty Ltd AS701 1371 1126 245 17.9% UUNET Technologies, Inc. AS577 324 198 126 38.9% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 821 703 118 14.4% AT&T AS6595 172 60 112 65.1% DoD Education Activity Network As AS4151 253 148 105 41.5% USDA AS705 307 203 104 33.9% UUNET Technologies, Inc. AS852 427 326 101 23.7% Telus Advanced Communications AS7046 318 232 86 27.0% UUNET Technologies, Inc. AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 186 105 81 43.5% State of Louisiana AS12302 111 32 79 71.2% MobiFon S.A. AS1239 479 403 76 15.9% Sprint AS4323 416 344 72 17.3% Time Warner Communications, Inc. AS3908 337 270 67 19.9% Supernet, Inc. AS4755 192 129 63 32.8% Videsh Sanchar Nigam Ltd. Autonom AS3464 157 97 60 38.2% Alabama SuperComputer Network AS703 275 216 59 21.5% UUNET Technologies, Inc. AS7303 107 49 58 54.2% Telecom Argentina Stet-France Tel AS724 212 154 58 27.4% DLA Systems Automation Center AS16758 63 6 57 90.5% IKON Office Solutions AS226 145 89 56 38.6% Los Nettos AS19834 63 8 55 87.3% NetForce, Inc. AS10620 77 22 55 71.4% TVCABLE BOGOTA AS702 624 570 54 8.7% UUNET Technologies, Inc. AS209 302 250 52 17.2% Qwest AS1 478 426 52 10.9% BBN Planet AS9051 74 23 51 68.9% INCONET Autonomous System AS2149 304 253 51 16.8% Performance Systems, Inc. Total 53554 41894 11660 21.8% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Transit Analysis
by Guy.Ram＠usa.telekom.de 15 Feb '02

15 Feb '02

> I'm trying to understand what techniques/solutions are available to > determine which AS's would make good peering partners. If we look at our > Transit stream to our upstream provider, I had heard the following from > someone and would like to get some other opinions: > > When trying to identify good AS candidates for peering from your transit > traffic stream. It would seem that distinguishing the ingress traffic by > not only the next-hop AS but also by the next-next-hop AS (or by the > complete AS path) so that you can identify which customer or peer of your > transit provider might be a likely interesting new peer for you. However, > due to the concept of BGP traffic in the internet being asymmetrically > distributed. It is not possible to exactly determine the real AS path of > incoming traffic. The only reliable information is about the next-hop and > the origin AS. Assuming that traffic is mostly symmetrical it is possible > to "estimate" the distribution of ingress traffic on AS paths. While this > assumption is questionable it at least allows to find out one (or some) of > the several "potential" intermediate" ASNs for a given origin ASNs. > > Is the above statement OK, and what about egress analysis, would that not > also provide useful as that information is more reliable? > > -guy > >

3 2

via the IP list...
by bmanning＠karoshi.com 15 Feb '02

15 Feb '02

http://www.newsbytes.com/news/02/174510.html The Federal Communications Commission (FCC) today said it has tentatively concluded that broadband Internet access provided over phone lines constitutes an "information service," and as such may not be subject to the open-access rules that govern the nation's phone networks. While the text of today's "notice of proposed rulemaking" probably won't be made publicly available for a couple days, the FCC signaled that it intends to remove some of the regulatory fetters that dictate how the nation's four Bell phone giants offer broadband services. <snip>

5 4

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