April 2004 - Test - lists.nanog.org

BGP session reset in one packet [where a looking glass or route server is available]
by David Luyer 21 Apr '04

21 Apr '04

It's not the general case, however... Some looking glass CGIs (in some cases, into production routers) permit "sh ip bgp nei <x>" -- try typing "sum" and then "nei x.x.x.x" into the "show ip bgp" box on a looking glass CGI, or using the command on a route server with CLI access. This gives you: Local host: [...], Local port: 179 Foreign host: [...], Foreign port: 29626 [...] iss: 770717974 snduna: 770746699 sndnxt: 770746699 sndwnd: 15472 irs: 431124262 rcvnxt: 440258849 rcvwnd: 15433 delrcvwnd: 951 [...] A traceroute will give you the information you need to estimate the TTL, and from there it's a single packet to reset the BGP session. If the looking glass is into a dedicated router, this achieves little more than causing the other routers to have to continually re-send their tables to the looking-glass; but if it's into a production router, well, it's a little more significant. And that _is_ sufficient to do a BGP session reset in one packet as the router is happily handing out sequence numbers, source and destination IP, source and destination port. Summary: if you don't want to do TCP MD5 auth on your BGP sessions, at least restrict "show tcp" and "show ip bgp nei" in all looking glasses and make sure your peers are not permitting them either in their directly attached routers. David.

1 0

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

Christopher / Patrick, > Christopher L. Morrow wrote: > I wasn't clear and for that I'm sorry. Except in the later > code trains, or until the recent past (1 year or so) changing > the BGP MD5 auth bits required the session to be reset. Then I'm the one sorry because I never got it to work (I have not tried hard, I have to say); I always considered the session reset to be annoyance that was part of life. Dumb question: on what platforms is this working? If my memory is correct nothing below the 7200; I have seen numerous cases of peering with platforms such as 3600. > no, removing a route-map or adding a new one is painful, > changing it is just normal, no bounce required. Maybe I have something to learn here. - The reason I have a route-map in for a peer's BGP session is that I want to want to shield myself against a misconfigured peer that announces the entire world to me. - There are cases (such as the peer being a tier-2 customer of UUNET and me being a tier-3 customer of UUNET via a different tier-2) when the routes seen coming from the peer will have the same length AS-PATH than the ones coming from my transit, some other BGP tie-breaking criteria favoring the peer over the transit, leading to disaster. - I have equally been burned by filtering using a regexp that accepts only routes that appear to originate from the peer. Looks good on paper but when the peer configures aggregates of their own that leak in their BGP, becomes messy. Also been burned with peers configuring next-hop-self. - I think I have a reasonably good understanding of route-maps; however I have not found so far a mechanism that could guarantee that, when adding/removing seqs from it, there is no transient condition that causes the peer wrongly announcing the entire world to you to get all his crud into my own table. - In theory, I could add a "route-map blah deny 1" that matches everything, then manipulate the subsequent seqs at will, then remove the "route-map blah deny 1"; in this situation though, I do not see a clear advantage over clearing the session. What am I missing? > wrong program, I was referring to his reset_tcp.c program, Oh, I see. I thought that you meant that saving the password somewhere was useless, as any side could recover it by decrypting it from the config. My mistake. > Remember that once you put the passwd in the config it's exposed > and the next NOC engineer that leaves will have a copy emailed to > his home email account before he stomps out :( You're preaching the choir on this. That being said, the point was how MD5 could diffuse a DOS attack based on the vulnerability mentioned earlier; the correlation between a BGP TCP RST DOS attack (especially against a big networks such as yours) and a NOC engineer leaving is not quite 1:1. As a matter of fact, if was a NOC engineer planning a DOS attack against the company I work for, I would stay in just to have the inside picture. > Patrick W.Gilmore wrote: > No medium or large network filters their peers on prefix. And > very few small networks do either. Prefix count, maybe, but > not individual prefixes. There are far too many changes on far > too many peers per day to keep up. Exactly the same argument as using MD5 or not. When you build this as part of the operation, yes it means time _and_ money but overall not that much more and the bigger the network the lesser the cost-per-router. I do concede that people such as Rob and myself are sometimes living on another planet, as there we operate a few networks for fun, not for money. Nevertheless, time for pet projects is limited is as well as day-time job ones, and if we lobby for something such as edge filtering or bogon route-servers, it's because it can be worked out. We just have the luxury to try without having to justify the time wasted on it. > Not to mention far, far, far too many chances to screw up > and get the dreaded phone call in the middle of the night. Irrelevant: 1) Look at your watch. 2) That's what rookies are for. A NOC rookie screwing up _one_ BGP session does not mean my phone rings. I'm sure that everyone understands that, when I was a rookie, I _never_ screwed up a session in the middle of the night when nobody cares :-) Michel.

3 2

RE: why use IPv6, was: Lazy network operators
by Michel Py 21 Apr '04

21 Apr '04

[consolidated some posts] > Alex Bligh wrote: > As an IPv6 skeptic I would note that some protocols NAT > extremely badly (SIP for instance), and the bodges to fix > it are costly. So if IPv6 means I can avoid NAT, that can > actually save $$$. Likely the market will find some other way, which is not to use a protocol that has problems in 80% of environments and to use one that works smoothly everywhere; have a look at Skype... Trouble crossing NAT has always been an excuse for people that design antiquated protocols. To some extent NAT is a benefit here as it will help to get rid of these. NAT is a reality; designing a protocol that does not cross it will only doom said protocol, not remove NAT. > Petri Helenius wrote: > We need one (or more) of the p2p vendors to support it. And why are they not doing it? More work, zero gain. Today, a p2p app has to cross NAT nicely and has to work over IPv4 nicely. Why bother with IPv6? It won't bring more users in. From the user's side: why bother with IPv6 since it works fine with v4? (if it was not working fine they would not use it in the first place). > Then IPv6 traffic will explode in three months to ~10-15% > of all internet traffic In your dreams. How much does threedegrees traffic account for? 0.0001%? 0.001%? Compare to Kazaa. > Patrick W.Gilmore wrote: > Dunno what your problem is, I have no problem getting as much > address space as I need as long as I can justify it. Perhaps > you need to speak to your provider? Agree. Actually, the situation is even worse than this: I have numerous customers that stockpile IPv4 addresses that they don't need just because they can have them (just in case). A typical 400-user organization with NAT needs only a dozen or two IPv4 addresses; however, I see more and more requesting 2 class Cs from their provider because they can justify the number. And there are number of bigger enterprises that multihome for the month they request their portable address space in order to get it, and then drop BGP and the second provider. > Iljitsch van Beijnum wrote: > [IPv6] Renumbering is much easier. What a joke. Have a look at this: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedu re-00.txt Then, ever tried to renumber a Windows 2000 domain controller? And please, save me the "Microsoft is crud" thing. 95% percent of the networks I renumbered had more than one. 75% of the renumbering hassle is orthogonal to the protocol being renumbered. > So currently, multi6 is looking at approaches that allow transport > protocols to jump addresses in the middle of a session. Which will be developed just the same for IPv4. > Paul Jakma wrote: > [snip darth vader] > Iljitsch van Beijnum wrote: > Michel, you forgot to include the audio: > http://www.bgpexpert.com/darkside.mp3 Cut/paste casualty! I requested the file from you 2 days ago for this very purpose! Paul, I'm surprised you missed the "dark side" thing. > Iljitsch van Beijnum wrote: > Michel is no longer in the IPv6 business, Wrong. I'm currently in the anti-IPv6 business. The dark side. > Paul Jakma wrote: > (how's your MHAP doing? I dumped it. > How's Iljitsch's geo-assigned addressing proposal? Right behind MHAP in oblivion land. At this very time, I think Iljitsch is wondering how to deal with Darth Py and Darth Jakma... > Well, let's be honest, name one good reason why you'd want > IPv6 (given you have 4)? And, to be more on-topic, name one > good reason why a network operator would want it? Especially > given that, apart from the traditional bleeding edges > academic networks), no customers are asking for it. You're preaching the choir. > But there _will_ be NAT, that is the very premise of this > discussion, as offered by Paul Vixie. And Tim Chown, and me, and plenty of others. > So that one doesnt count, unless you knock down the premise: > There will be site-local and NAT with v6 because of the > multihoming problem. I used to think that way, but no longer. When we started ipv6mh, there was still a chance that providing a reasonable multihoming solution would get IPv6 out the mud hole. Trouble is that there were developments in other sectors of IPv6 that I was not able to foreseen have changed the situation to a point where IPv6 multihoming is no more that a bug on the windshield of IETF backroom politics, to re-use Vixie's words. For everyone, here's the bottom line: - Today, what to do with IPv6 is simple: nothing. Whether you are an end-user/small business, large enterprise or provider everyone is in the same situation: is costs money to upgrade, causes trouble, not the only thing we have to do anyway, there is no demand and therefore no ROI. It is urgent to wait. IPv6 is in a very similar situation ISDN was some time ago: I Still Don't Need. - - - - - Tomorrow, IPv4 will get the small upgrades that are needed. Michel.

3 3

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

Patrick / Christopher, >> Michel Py wrote: >> Please forgive me if I'm naive and/or ask a stupid question, >> but is there any reason (besides your platform not supporting >> it) _not_ to MD5 your BGP sessions? Geez, on my _home_ router >> all my v4 BGP sessions are MD5ed (v6 not there yet). > Patrick W.Gilmore wrote: > There is serious operational overhead in maintaining sync'ed > passwords between separate organizations. IOW: Eventually > someone will screw up and lose the password. > [large snip] Thanks for the insight. I have an even dumber question: Context: set aside the MD5, the way I configure BGP sessions/traffic from/to peers is as follows: a) A generic (configured in the peer-group) route-map to filter the routes I announce to the peer to be only my blocks. b) A specific-to-the-peer route-map to filter the routes I receive from the peer to the peer's blocks, as agreed in the beer drinking meeting ^H^H^H^H BLPA. This route map is not entirely specific, as I also put in stuff such as deny RFC1918 routes ;-) c) A generic access-list filtering ingress traffic from the peer to me to allow only traffic which DA is mine. (cracks me up if the peer sets a default to me :-) d) A generic access-list filtering egress traffic from me to the peer to allow only traffic which SA is mine. Now, the dumb question: Given: 1) The context above especially item b 2) Christopher Morrow's comments below Explain me what having or not having the MD5 password changes. Either you're small and/or stupid and do it manually, or you have an automated system that does it for you. > Christopher L. Morrow wrote: > there is the issue of changing the keys during operations > without impacting the network, eh? Having to bounce every > bgp session in your network can be pretty darned painful... > if you change the key(s) of course. See above: Changing the route-map is equally painful. > If you don't you might as well not have keys, since adding > the 3 lines of C code required to Paul Watsons' program > making it do the hashing certainly won't be a big deal, eh? I'm weak with C. Besides adding "neighbor x.x.x.x password 7 " below "enable-password 7 " for each peer (which requires recompiling, how annoying) would you care sharing the 3 said lines for the code below :-) Michel. #include <stdio.h> #include <ctype.h> char xlat[] = { 0x64, 0x73, 0x66, 0x64, 0x3b, 0x6b, 0x66, 0x6f, 0x41, 0x2c, 0x2e, 0x69, 0x79, 0x65, 0x77, 0x72, 0x6b, 0x6c, 0x64, 0x4a, 0x4b, 0x44 }; char pw_str1[] = "password 7 "; char pw_str2[] = "enable-password 7 "; char *pname; cdecrypt(enc_pw, dec_pw) char *enc_pw; char *dec_pw; { unsigned int seed, i, val = 0; if(strlen(enc_pw) & 1) return(-1); seed = (enc_pw[0] - '0') * 10 + enc_pw[1] - '0'; if (seed > 15 || !isdigit(enc_pw[0]) || !isdigit(enc_pw[1])) return(-1); for (i = 2 ; i <= strlen(enc_pw); i++) { if(i !=2 && !(i & 1)) { dec_pw[i / 2 - 2] = val ^ xlat[seed++]; val = 0; } val *= 16; if(isdigit(enc_pw[i] = toupper(enc_pw[i]))) { val += enc_pw[i] - '0'; continue; } if(enc_pw[i] >= 'A' && enc_pw[i] <= 'F') { val += enc_pw[i] - 'A' + 10; continue; } if(strlen(enc_pw) != i) return(-1); } dec_pw[++i / 2] = 0; return(0); } usage() { fprintf(stdout, "Usage: %s -p <encrypted password>\n", pname); fprintf(stdout, " %s <router config file> <output file>\n", pname); return(0); } main(argc,argv) int argc; char **argv; { FILE *in = stdin, *out = stdout; char line[257]; char passwd[65]; unsigned int i, pw_pos; pname = argv[0]; if(argc > 1) { if(argc > 3) { usage(); exit(1); } if(argv[1][0] == '-') { switch(argv[1][1]) { case 'h': usage(); break; case 'p': if(cdecrypt(argv[2], passwd)) { fprintf(stderr, "Error.\n"); exit(1); } fprintf(stdout, "password: %s\n", passwd); break; default: fprintf(stderr, "%s: unknow option.", pname); } return(0); } if((in = fopen(argv[1], "rt")) == NULL) exit(1); if(argc > 2) if((out = fopen(argv[2], "wt")) == NULL) exit(1); } while(1) { for(i = 0; i < 256; i++) { if((line[i] = fgetc(in)) == EOF) { if(i) break; fclose(in); fclose(out); return(0); } if(line[i] == '\r') i--; if(line[i] == '\n') break; } pw_pos = 0; line[i] = 0; if(!strncmp(line, pw_str1, strlen(pw_str1))) pw_pos = strlen(pw_str1); if(!strncmp(line, pw_str2, strlen(pw_str2))) pw_pos = strlen(pw_str2); if(!pw_pos) { fprintf(stdout, "%s\n", line); continue; } if(cdecrypt(&line[pw_pos], passwd)) { fprintf(stderr, "Error.\n"); exit(1); } else { if(pw_pos == strlen(pw_str1)) fprintf(out, "%s", pw_str1); else fprintf(out, "%s", pw_str2); fprintf(out, "%s\n", passwd); } } }

3 2

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

> Rob Thomas wrote: > We manage well over 150 peering sessions with MD5 passwords > in place. This includes bogon peering, route-server peering, > and production traffic peering. This has grown over the past > three years. The total number of MD5-related outages: zero. I have to complain about this: MD5 peering with Team Cymru is boring. I have has some scheduled (and announced prior-to-happening) maintenance outages, but if one has (I do) redundant peering with them, it never goes down and nothing interesting ever happens. Rob, screw up the config from time to time, would you? If nothing ever goes down, half of the readers will be out of a job soon. Michel.

1 0

Nmap to print out the MAC addresses of scanned hosts
by Cemil Degirmenci 20 Apr '04

20 Apr '04

Hello There, maybe Offtopic, but i thought this could be interesting for some of you. Nmap 3.51-TEST3 is released with some nice new features for local networks. Nmap now uses the system interface table (as shown by ifconfig) to determine whether a system is on the same network. A database derived from the one distributed by the IEEE is then consulted to report the manufacturer. Here are examples from normal and XML output: MAC Address: 08:00:20:8F:6B:2F (SUN Microsystems Inc.) <address addr="00:A0:CC:63:85:4B" vendor="Lite-on Communications, Inc." addrtype="mac" /> This will maybe helpful for network administrators to track down problem machines (worm-infected, spammers, etc.) This also helps track changes on DHCP networks where the IP addresses can change frequently. its still in development but seems to work well. -- Mit freundlichen Gruessen / kind regards, Cemil Degirmenci wavecon.de

1 0

Cisco Security Advisory: Vulnerabilities in SNMP Message Processing
by Cisco Systems Product Security Incident Response Team 20 Apr '04

20 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Vulnerabilities in SNMP Message Processing Revision 1.0 INTERIM For Public Release 2004 April 20 UTC 2100 - ----------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures - ----------------------------------------------------------------------- Summary ======= Cisco Internetwork Operating System (IOS) Software releases trains 12.0S, 12.1E, 12.2, 12.2S, 12.3, 12.3B and 12.3T may contain a vulnerability in processing SNMP requests which, if exploited, could cause the device to reload. The vulnerability is only present in certain IOS releases on Cisco routers and switches. This behavior was introduced via a code change and is resolved with CSCed68575. This vulnerability can be remotely triggered. A successful exploitation of this vulnerability may cause a reload of the device and could be exploited repeatedly to produce a Denial of Service (DoS). This advisory is available at: http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml Affected Products ================= This vulnerability was introduced by a code change for CSCeb22276. This change was committed to the following releases, causing these releases to be vulnerable. Note: The list below is not comprehensive; it is provided to help quickly identify some commonly used releases. Please see the Software Versions and Fixes section of this advisory for the complete IOS upgrade table. * 12.0(23)S4, 12.0(23)S5 * 12.0(24)S4, 12.0(24)S5 * 12.0(26)S1 * 12.0(27)S * 12.0(27)SV, 12.0(27)SV1 * 12.1(20)E, 12.1(20)E1, 12.1(20)E2 * 12.1(20)EA1 * 12.1(20)EW, 12.1(20)EW1 * 12.1(20)EC, 12.1(20)EC1 * 12.2(12g), 12.2(12h) * 12.2(20)S, 12.2(20)S1 * 12.2(21), 12.2(21a) * 12.2(23) * 12.3(2)XC1, 12.3(2)XC2 * 12.3(5), 12.3(5a), 12.3(5b) * 12.3(6) * 12.3(4)T, 12.3(4)T1, 12.3(4)T2, 12.3(4)T3 * 12.3(5a)B * 12.3(4)XD, 12.3(4)XD1 To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running IOS release 12.0(3) with an installed image name of C2500-IS-L: Cisco Internetwork Operating System Software IOS (TM) 2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE The release train label is "12.0". The next example shows a product running IOS release 12.0(2a)T1 with an image name of C2600-JS-MZ: Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-JS-MZ), Version 12.0(2a)T1, RELEASE SOFTWARE (fc1) Additional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html. Details ======= The Simple Network Management Protocol (SNMP) defines a standard mechanism for remote management and monitoring of devices in an Internet Protocol (IP) network. A device or host that supports SNMP is an SNMP entity. There are two classes of SNMP entities: SNMP managers that request information and receive unsolicited messages and SNMP agents that respond to requests and send unsolicited messages. SNMP entities that support SNMP proxy functions combine the functions of both SNMP manager and SNMP agent. There are two classes of SNMP operations: solicited operations such as 'get' or 'set', with which the SNMP manager requests or changes the value of a managed object on an SNMP agent; and unsolicited operations such as 'trap' or 'inform' messages with which the SNMP agent provides an unsolicited notification or alarm message to the SNMP manager. The 'inform' operation is essentially an acknowledged 'trap'. All SNMP operations are transported over the User Datagram Protocol (UDP). Solicited operations are sent by the SNMP manager to the UDP destination port 161 on the agent. Unsolicited operations are sent by the SNMP agent to the UDP destination port 162. In IOS, The acknowledgement sent by the SNMP manager to an SNMP agent in reply to an 'inform' operation is sent to a randomly chosen high port that is chosen when the SNMP process is started. As IOS implements both an SNMP agent and SNMP proxy functionality, the SNMP process in IOS starts listening for SNMP operations on UDP ports 161, 162 and the random UDP port at the time it is initialized. The SNMP process is started either at the time the device boots, or when SNMP is configured. The high port is chosen via the following series of steps: 1. A random number between 49152 and 59152 is generated. 2. IOS checks to see if that UDP port is already being used. If not, that UDP port is selected to receive SNMP 'inform' acknowledge messages. 3. If the port is already in use, IOS increments the port number by 1, and checks again, incrementing until an open port is found. Therefore, the port chosen may be higher than 59152 although this is considered unlikely. In this vulnerability, the IOS SNMP process is incorrectly attempting to process SNMP solicited operations on UDP port 162 and the random UDP port. Upon attempting to process a solicited SNMP operation on one of those ports, the device can experience memory corruption and may reload. SNMPv1 and SNMPv2c solicited operations to the vulnerable ports will perform an authentication check against the SNMP community string, which may be used to mitigate attacks. Through best practices of hard to guess community strings and community string ACLs, this vulnerability may be mitigated for both SNMPv1 and SNMPv2c. However, any SNMPv3 solicited operation to the vulnerable ports will reset the device. If configured for SNMP, all affected versions will process SNMP version 1, 2c and 3 operations. This vulnerability was introduced by DDTS CSCeb22276 and has been corrected with DDTS CSCed68575. Impact ====== Successful exploitation of this vulnerability results in a reload of the device. Repeated exploitation could result in a sustained DoS attack. Software Versions and Fixes =========================== Be advised that Cisco released multiple advisories on 2004-April-20. When considering software upgrades, please also consult http://www.cisco.com/warp/public/707/advisory.html and any subsequent advisories to determine exposure and a complete upgrade solution. Each row of the Cisco IOS software table (below) describes a release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild," "Interim," and "Maintenance" columns. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label). When selecting a release, keep in mind the following definitions: * Maintenance - Most heavily tested, stable, and highly recommended release of a release train in any given row of the table. * Rebuild - Constructed from the previous maintenance or major release in the same train, it contains the fix for a specific defect. Although it receives less testing, it contains only the minimal changes necessary to repair the vulnerability. * Interim - Built at regular intervals between maintenance releases and receives less testing. Interims should be selected only if there is no other suitable release that addresses the vulnerability. Interim images should be upgraded to the next available maintenance release as soon as possible. Interim releases are not available through manufacturing, and usually they are not available for customer download from CCO without prior arrangement with the Cisco TAC. To find the information for a given IOS release, compare the release number as reported by the show version command to the major releases in the first column below. For example, if your device reports that it is running 12.3(5), find the row in the table for "12.3". Reading across to the right, you find 12.3(5c) in the Rebuild column, indicating that 12.3(5) through 12.3(5b) are vulnerable. Since 12.3(5c) is already available for download from CCO, you could upgrade to it as soon as possible. If a release train is labeled "Vulnerable", then migration to another release train should be considered. Except where a release label in a different release train is explicitly identified in the table below, customers should contact the Cisco TAC for assistance to identify the appropriate migration path. If migration is not possible, then workarounds may be the only alternative. In all cases, customers should exercise caution to confirm that the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new software release. If the information is not clear, contact the Cisco TAC for assistance as shown in the "Obtaining Fixed Software" section below. More information on Cisco IOS software release names and abbreviations is available at http://www.cisco.com/warp/public/620/1.html. The fixes will be available at the Software Center located at http://www.cisco.com/public/sw-center/. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |-------------------+-----------------------------------------------| | Affected 12.0 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.0(23)S6 | | | | |---------------+---------------+---------------| | | 12.0(24)S6 - | | | | | Due on CCO | | | | 12.0S | mid-May, | | | | | 2004. | | | | |---------------+---------------+---------------| | | 12.0(26)S2 | | | | |---------------+---------------+---------------| | | 12.0(27)S1 | | | |-------------------+---------------+---------------+---------------| | | 12.0(27)SV2 - | | | | 12.0SV | contact TAC. | | | | | Available | | | | | upon request. | | | |-------------------+---------------+---------------+---------------| | Affected 12.1 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)E3 - | | | | | Due on CCO | | | | | April 20, | | | | | 2004. | | | | 12.1E |---------------+---------------+---------------| | | 12.1(22)E1 - | | | | | Due on CCO | | | | | April 20, | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)EA1a | | | | 12.1EA | - Due on CCO | | | | | April 21, | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)EC2 - | | | | 12.1EC | contact TAC. | | | | | Available | | | | | upon request. | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)EW2 - | | | | 12.1EW | Due on CCO | | | | | April 21, | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | Affected 12.2 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.2(12i) | | | | |---------------+---------------+---------------| | | 12.2(21b) | | | | |---------------+---------------+---------------| | 12.2 | | 12.2(23.6) - | 12.2(24) - | | | | available | Due on CCO | | | | upon request. | mid-May, | | | | | 2004. | | |---------------+---------------+---------------| | | 12.2(23a) | | | |-------------------+---------------+---------------+---------------| | | 12.2(20)S2 | | | | 12.2S |---------------+---------------+---------------| | | 12.2(22)S | | | |-------------------+---------------+---------------+---------------| | Affected 12.3 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.3(5c) | | | | |---------------+---------------+---------------| | | 12.3(6a) | | | | 12.3 |---------------+---------------+---------------| | | | 12.3(7.7) - | 12.3(9) - Due | | | | available | on CCO | | | | upon request. | mid-May, | | | | | 2004. | |-------------------+---------------+---------------+---------------| | | 12.3(5)B1 - | | | | 12.3B | Due on CCO | | | | | mid-June | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | | 12.3(4)T4 | | | | 12.3T |---------------+---------------+---------------| | | 12.3(7)T | | | |-------------------+---------------+---------------+---------------| | | 12.3(2)XC3 - | | | | 12.3XC | contact TAC | | | | | Available | | | | | upon request. | | | |-------------------+---------------+---------------+---------------| | 12.3XD | 12.3(4)XD2 | | | |-------------------+---------------+---------------+---------------| | 12.3XH | 12.3(4)XH | | | |-------------------+---------------+---------------+---------------| | 12.3XK | 12.3(4)XK | | | |-------------------+---------------+---------------+---------------| | 12.3XQ | 12.3(4)XQ | | | +-------------------------------------------------------------------+ Obtaining Fixed Software ======================== Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com/. Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with the upgrade, which is free of charge. Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their free of charge upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" for software upgrades. Workarounds =========== The effectiveness of any workarounds is dependent on specific customer situations such as product mix, network topology, traffic behavior and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround is the most appropriate for use in the intended network before it is deployed. The following workarounds should only be considered as a long term solution if anti-spoofing methods consistently prevent spoofed source attacks from entering the network and access-lists provided below are configured on every potentially affected device. * It is possible to disable SNMP processing on the device running IOS by issuing the following command: no snmp-server Removing the public community string with the configure command 'no snmp-server community <string> ro' is not sufficient as the SNMP server will still be running and the device will be vulnerable. The command no snmp-server must be used instead. Verify SNMP server status by using the enable command show snmp. You should see a response of "%SNMP agent not enabled". * Access Control Lists (ACLs) can be used to deny traffic tot he affected ports. As there can be no guarantee that the random high port will fall in the range of 49152 to 59152 (possibly as high as 65535), the example access-lists below show how to block all UDP ports in the range 49152 to 65535. Care should be taken to understand the potential side effects noted later in this section. Although Cisco IOS devices have community-string access lists which check the source address of SNMP requests per community string, they will not be sufficient to mitigate this vulnerability due to the SNMPv3 exploitation vector. On platforms that do not have the option to use rACLs, it is possible to permit UDP traffic to the router from trusted IP addresses with interface ACLs. Note: Because SNMP is based on UDP, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. The following extended access-list can be adapted to your network. This example assumes that the router has IP addresses 192.168.10.1 and 172.16.1.1 configured on its interfaces, that all SNMP access is to be restricted to a management station with the IP address of 10.1.1.1, and that the management station need only communicate with IP address 192.168.10.1: access-list 101 permit udp host 10.1.1.1 host 192.168.10.1 range 161 162 access-list 101 permit udp host 10.1.1.1 host 192.168.10.1 range 49152 65535 access-list 101 deny udp any host 192.168.10.1 range 161 162 access-list 101 deny udp any host 192.168.10.1 range 49152 65535 access-list 101 deny udp any host 172.16.1.1 range 161 162 access-list 101 deny udp any host 172.16.1.1 range 49152 65535 access-list 101 permit ip any any The access-list must then be applied to all interfaces using the following configuration commands: interface ethernet 0/0 ip access-group 101 in Note that UDP traffic in the ranges specified above must be explicitly blocked to each IP address on the router to prevent the router from accepting and processing the SNMP packets. Additionally, while blocking traffic to port 161 from unknown hosts is a best practice, in this case, port 161 is not affected and need not be blocked to prevent exploitation. All devices that communicate directly with the router on those UDP ports will need to be specifically listed in the above access list. Cisco IOS uses ports in the range 49152 to 65535 as the source port for outbound sessions such as DNS queries. For devices that have many IP addresses configured, or many hosts that need to communicate with the router, this may not be a scalable solution. IMPORTANT NOTE: Cisco IOS uses the same source port range when upgrading via TFTP. If your upgrade process includes downloading from a TFTP server, be sure to permit UDP traffic in the range 49152 to 65535 between the router and the TFTP server. Alternative download methods that do not rely on UDP, such as FTP, may also be used. Besides TFTP, other potentially affected services include Network Time Protocol (NTP), Remote Authentication Dial In User Service (RADIUS) and Domain Name Service (DNS). To minimize the impact of this workaround, you may want to explicitly permit access between your IOS device and the servers providing the service(s). It is critically important that you understand the impact to your network before deploying the above workaround. * Blocking Individual Ports The high port number chosen by the IOS device can be determined by using the command show ip sockets. UDP traffic to that individual port can be blocked, rather than the entire port range. This approach is not ideal because the high port is chosen at random when the router is rebooted or the SNMP service is stopped and restarted. This may, however, be a short term solution for customers that want to protect themselves from the vulnerability as they prepare to upgrade, for example. Output of the show ip sockets command: Router#sh ip sockets Proto Remote Port Local Port In Out Stat TTY OutputIF [snip] 17 --listen-- 192.168.10.72 161 0 0 1 0 17 --listen-- 192.168.10.72 162 0 0 11 0 17 --listen-- 192.168.10.72 49212 0 0 11 0 The above example shows that there are 3 SNMP-related ports listening, and the high port is bound to 49212. Rather than blocking the entire port range from 49152 to 65535, port 49212 can be blocked (in addition to port 162) as a temporary workaround. * Receive ACLs (rACL) For distributed platforms, rACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 series GSR and 12.0 (24)S for the 7500 series. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. Receive path ACLs are considered a network security best practice, and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/public/707/racl.html * Infrastructure ACLs (iACL) Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for iACLs: http://www.cisco.com/warp/public/707/iacl.html Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. Status of This Notice: INTERIM ============================== This is a INTERIM advisory. Although Cisco cannot guarantee the accuracy of all statements in this advisory, all of the facts have been checked to the best of our ability. Cisco may issue updated versions of this advisory A stand-alone copy or paraphrase of the text of this security advisory that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory will be posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * bugtraq(a)securityfocus.com * first-teams(a)first.org (includes CERT/CC) * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.netsys.com * vulnwatch(a)vulnwatch.org * comp.dcom.sys.cisco * Various other mailing lists Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +----------------------------------------+ | Revision | | Initial | | 1.0 | 2004-April-20 | Public | | | | Release. | +----------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFAhZdvezGozzK2tZARAoj8AJsGfguxTnZ7P1KbzBdvVdtIizBYvQCeOOE2 jCByoWAz5y72MveH0NMXwXs= =Nfq3 -----END PGP SIGNATURE-----

1 0

Re: TCP vulnerability
by Aviva Garrett 20 Apr '04

20 Apr '04

In message <1386.64.235.224.55.1082482608.squirrel(a)mail.mzima.net>you write: > > Since no one's mentioned it yet, apparently there was a change in plans. > It was just released a day early. This is because of the story at http://www.washingtonpost.com/, in the Technology section. Thanks, ..Aviva > > http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_o… > hi_te/internet_threat > > And the official one: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > Grant > > -- > Grant A. Kirkwood - grant(at)tnarg.org > Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

5 5

RE: Winstar says there is no TCP/BGP vulnerability
by McBurnett, Jim 20 Apr '04

20 Apr '04

Well, CERT thought it was Jim -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP Overview Most implementations of the Border Gateway Protocol (BGP) rely on the Transmission Control Protocol (TCP) to maintain persistent unauthenticated network sessions. There is a vulnerability in TCP which allows remote attackers to terminate network sessions. Sustained exploitation of this vulnerability could lead to a denial of service condition; in the case of BGP systems, portions of the Internet community may be affected. Routing operations would recover quickly after such attacks ended. I. Description In 2001, the CERT Coordination Center released CA-2001-09, describing statistical weaknesses in various TCP/IP Initial Sequence generators. In that document (<http://www.cert.org/advisories/CA-2001-09.html>), it was noted by Tim Newsham: [I]f a sequence number within the receive window is known, an attacker can inject data into the session stream or terminate the connection. If the ISN value is known and the number of bytes sent already sent is known, an attacker can send a simple packet to inject data or kill the session. If these values are not known exactly, but an attacker can guess a suitable range of values, he can send out a number of packets with different sequence numbers in the range until one is accepted. The attacker need not send a packet for every sequence number, but can send packets with sequence numbers a window-size apart. If the appropriate range of sequence numbers is covered, one of these packets will be accepted. The total number of packets that needs to be sent is then given by the range to be covered divided by the fraction of the window size that is used as an increment. Paul Watson has performed the statistical analysis of this attack when the ISN is not known and has pointed out that such an attack could be viable when specifically taking into account the TCP Window size. He has also created a proof-of-concept tool demonstrating the practicality of the attack. The National Infrastructure Security Co-Ordination Centre (NISCC) has published an advisory summarizing Paul Watson's analysis in "NISCC Vulnerability Advisory 236929," available at <http://www.uniras.gov.uk/vuls/2004/236929/index.htm>. Since TCP is an insecure protocol, it is possible to inject transport-layer packets into sessions between hosts given the right preconditions. The TCP/IP Initial Sequence Number vulnerability (http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is one example of how an attacker could inject TCP packets into a session. If an attacker were to send a Reset (RST) packet for example, they would cause the TCP session between two endpoints to terminate without any further communication. The Border Gateway Protocol (BGP) is used to exchange routing information for the Internet and is primarily used by Internet Service Providers (ISPs). For detailed information about BGP and some tips for securing it, please see Cisco System's documentation (<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm> or Team Cymru (<http://www.cymru.com/>). A vulnerable situation arises due to the fact that BGP relies on long-lived persistent TCP sessions with larger window sizes to function. When a BGP session is disrupted, the BGP application restarts and attempts to re-establish a connection to its peers. This may result in a brief loss of service until the fresh routing tables are created. In a TCP session, the endpoints can negotiate a TCP Window size. When this is taken into account, instead of attempting to send a spoofed packet with all potential sequence numbers, the attacker would only need to calculate an valid sequence number that falls within the next expected ISN plus or minus half the window size. Therefore, the larger the TCP Window size, the the larger the range of sequence numbers that will be accepted in the TCP stream. According to Paul Watson's report, with a typical xDSL data connection (80 Kbps, upstream) capable of sending of 250 packets per second (pps) to a session with a TCP Window size of 65,535 bytes, it would be possible to inject a TCP packet approximately every 5 minutes. It would take approximately 15 seconds with a T-1 (1.544 Mbps) connection. These numbers are significant when large numbers of compromised machines (often called "botnets" or "zombies") can be used to generate large amounts of packets that can be directed at a particular host. To protect against such injections, RFC 2385 provides a method of using MD5 signatures on the TCP Headers. If this form of verification is supported and enabled between two peers, then an attacker would have to obtain the key used to transmit the packet in order to successfully inject a packet into the TCP session. Another alternative would be to tunnel BGP over IPSec. Again, this would provide a form of authentication between the BGP peers and the data that they transmit. The lack of authentication when using TCP for BGP makes this type of attack more viable. US-CERT is tracking this issue as VU#415294. This reference number corresponds to CVE candidate CAN-2004-0230. NISCC is tracking this issue as Advisory 236929. II. Impact Sustained exploitation of the TCP injection vulnerability with regard to the BGP vulnerability could lead to a denial-of-service condition that could affect a large segment of the Internet community. Normal operations would most likely resume shortly after the attack stopped. Since the TCP/IP Initial Sequence Number vulnerability (VU#498440) has been proven more viable of an attack, any services or sites that rely on persistent TCP sessions could also be affected by this vulnerability. Impacts could range from data corruption or session hijacking to a denial-of-service condition. III. Solution Apply a patch from your vendor Please see you vendor's statement regarding the availability of patches, updates and mitigation strategies. Workaround Deploy and Use Cryptographically Secure Protocols TCP initial sequence numbers were not designed to provide proof against TCP connection attacks. The lack of cryptographically-strong security options for the TCP header itself is a deficiency that technologies like IPSec try to address. It must be noted that in the final analysis that if an attacker has the ability to see unencrypted TCP traffic generated from a site, that site is vulnerable to various TCP attacks - not just those mentioned here. A stronger measure that would aid in protecting against such TCP attacks is end-to-end cryptographic solutions like those outlined in various IPSec documents. The key idea with an end-to-end cryptographic solution is that there is some secure verification that a given packet belongs in a particular stream. However, the communications layer at which this cryptography is implemented will determine its effectiveness in repelling ISN based attacks. Solutions that operate above the Transport Layer (OSI Layer 4), such as SSL/TLS and SSH1/SSH2, only prevent arbitrary packets from being inserted into a session. They are unable to prevent a connection reset (denial of service) since the connection handling will be done by a lower level protocol (i.e., TCP). On the other hand, Network Layer (OSI Layer 3) cryptographic solutions such as IPSec prevent both arbitrary packets entering a transport-layer stream and connection resets because connection management is directly integrated into the secure Network Layer security model. The solutions presented above have the desirable attribute of not requiring any changes to the TCP protocol or implementations to be made. Some sites may want to investigate hardening the TCP transport layer itself. RFC2385 ("Protection of BGP Sessions via the TCP MD5 Signature Option") and other technologies provide options for adding cryptographic protection within the TCP header at the cost of some potential denial of service, interoperability, and performance issues. Ingress filtering Ingress filtering manages the flow of traffic as it enters a network under your administrative control. You can configure your BGP routers to only accept packets on a specific network connection. Servers are typically the only machines that need to accept inbound connections from the public Internet. In the network usage policy of many sites, there are few reasons for external hosts to initiate inbound connections to machines that provide no public services. Thus, ingress filtering should be performed at the border to prohibit externally initiated inbound connections to non-authorized services. In this fashion, the effectiveness of many intruder scanning techniques can be dramatically reduced. Network Isolation Complex networks can benefit by separating data channels and control channels, such as BGP, into different logical or physical networks. Technologies such as VLANs, VPNs, leased links, NAT may all be able to contribute to separating the tranmission of control information from the transmission of the data stream. Egress filtering Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is typically limited need for machines providing public services to initiate outbound connections to the Internet. In the case of BGP, only your BGP routers should be establishing connections to your peers. Other BGP traffic generated on your network could be a sign of an attempted attack. Appendix A. Vendor Information For vendor information, please see NISCC Vulnerability Advisory 236929 "Vulnerability Issues in TCP" (http://www.uniras.gov.uk/vuls/2004/236929/index.htm) or Vulnerability Note VU#415294 (http://www.kb.cert.org/vuls/id/415294#systems. As vendors report new information to US-CERT, we will update the vulnerability note. If a particular vendor is not listed in either the NISCC advisory, or the vulnerability, we recommend that you contact them for their comments. _________________________________________________________________ US-CERT thanks Paul Watson, Cisco Systems and NISCC for notifying us about this problem and for helping us to construct this advisory. _________________________________________________________________ Feedback can be directed to the US-CERT Technical Staff. _________________________________________________________________ Copyright 2004 Carnegie Mellon University. Terms of use Revision History April 20, 2004: Initial release Last updated April 20, 2004 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAhXn2XlvNRxAkFWARAjKIAKDPl3a6RADvUASZJnIz5MAolUygqACgvUXz crcQkqHTAxSVkcKnMMYLYU0= =54p4 -----END PGP SIGNATURE-----

1 0

RE: Backbone IP network Economics - peering and transit
by Gary Hale 20 Apr '04

20 Apr '04

I disagree ... but sure do appreciate your tone ... :) Regards, Gary -----Original Message----- From: Daniel Golding [mailto:dgolding@burtongroup.com] Sent: Tuesday, April 20, 2004 4:32 PM To: Gary Hale; Michel Py; Gordon Cook; nanog(a)merit.edu Subject: Re: Backbone IP network Economics - peering and transit Cynical? Gee, I hope so. Anyone who reads that sort of fluff needs to be cynical. Lack of appropriate cynicism led, in part, to the "recent unpleasantness" in the telecommunications industry. Words like "enabling", "leveraging", "mindshare", "b2b", "e-*", "i-*", et al, are considered harmful to fruitful operational discussion :) -- Daniel Golding Network and Telecommunications Strategies Burton Group On 4/20/04 2:17 PM, "Gary Hale" <ghale(a)globalinternetworking.com> wrote: > Daniel, > > That is way too cynical ... and does not address the question of whether > building your own transport ever runs counter to the Internet as a > consortium. > > There are business justifications that underpin peering relationships > ... and they are based on understanding (or ... "philosophy") .... > > Gary > > -----Original Message----- > From: Daniel Golding [mailto:dgolding@burtongroup.com] > Sent: Tuesday, April 20, 2004 10:36 AM > To: Gary Hale; Michel Py; Gordon Cook; nanog(a)merit.edu > Subject: Re: Backbone IP network Economics - peering and transit > > On 4/20/04 8:45 AM, "Gary Hale" <ghale(a)globalinternetworking.com> wrote: > >> >> The question is too simplistic ... It is not (simply) a matter of > small >> vs. big or being on your own network from source-to-destination. > Peering >> is an enabler ... and gives all an opportunity to share content > globally >> ... kinda' fundamental to the Internet consortium. >> >> Is your question, 'Since fiber is so cheap, why doesn't everyone build >> an autonomous, facilities-based, global "Internet" network that > competes >> for narrowband/broadband "pullers" of data and hosting/data > centers/etc. >> for content providers ("pulled-fromers" or "pushers" of data)? >> >> Gary >> >> -----Original Message----- >> From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] >> Sent: Monday, April 19, 2004 10:46 PM >> To: Gordon Cook; nanog(a)merit.edu >> Subject: RE: Backbone IP network Economics - peering and transit >> >> >>> Peering? Who needs peering if transit can be >>> had for $20 per megabit per second? >> >> The smaller guys that don't buy transit buy the gigabit. >> >> Michel. >> >> >> > Gary, > > "Peering is an enabler" > "gives all an opportunity to share content globally" > "fundamental to the Internet consortium" > > This is like the "greatest hits" compendium collected from various > failed > 1990's service provider business plans :) > > People should be careful. Peering is a business/networking arrangement > that > can save them money (or not). Those who try to imbue it with > philosophical > significance must be viewed with skepticism. > > > Daniel Golding > Network and Telecommunications Strategies > Burton Group > > > >

1 0