November 1997 - NANOG - lists.nanog.org

Updated notice on Cisco and land.c
by John Bashinski 22 Nov '97

22 Nov '97

This is an update to the previous notice. I originally planned just to have this updated on the Web site and to post a pointer to the updated Web page, but the Web posting seems to be taking a really long time, and I don't want to delay the notice any longer. This version will eventually (probably by the time most of you read this) be posted at http://www.cisco.com/warp/public/770/land-pub.shtml That URL will be updated with future versions. We probably won't send the whole text out again. Important differences between this notice and the last one: o There are definitely versions of classis Cisco IOS software that are badly affected by the land.c attack. o The notice contains detailed information about which IOS versions are affected. o Catalyst 5000s, and probably other Catalyst switches, are affected. o Various editing and advice changes... nothing really substantive. -- John B. -----BEGIN PGP SIGNED MESSAGE----- Field Notice: TCP loopback DoS Attack (land.c) and Cisco Devices November 22, 1997, 08:00 AM US/Pacific, Revision 2 ========================================================================= Summary ======= Somebody has released a program, known as land.c, which can be used to launch denial of service attacks against various TCP implementations. The program sends a TCP SYN packet (a connection initiation), giving the target host's address as both source and destination, and using the same port on the target host as both source and destination. Classic Cisco IOS software (used on Cisco routers with product numbers greater than 1000, on the CGS/MGS/AGS+, and on the CS-500) is vulnerable to this attack, depending on the software version. See the section on "Affected Cisco IOS Software Versions" in this document for information on affected versions. Cisco IOS/700 software (used on Cisco 7xx routers) is also vulnerable. The 7xx vulnerability is more devastating than the classic Cisco IOS software vulnerability, but probably less dangerous for most customers, since firewalls separate most 7xx routers from the Internet. Cisco Catalyst 5000 LAN switches are vulnerable. Other Cisco Catalyst LAN switches are probably also vulnerable. The PIX firewall appears does not appear to be affected. Initial testing of the Centri firewall tends to indicate that it is not affected. We're working on characterizing other products' vulnerability to attack. Updates will be issued as information becomes available. Who is Affected =============== All Cisco IOS/700 software and Cisco Catalyst systems that can be reached via TCP from untrusted hosts are affected. Cisco IOS software systems that are running vulnerable versions and that can be reached via TCP from untrusted hosts are affected. In all cases, the TCP ports reachable by the attack must be ports on which services are actually being provided (such as the TELNET port, for most systems). The attack requires spoofing the targets's own address, so systems behind effective anti-spoofing firewalls are safe. Impact ====== This vulnerability allows attackers to deny service to legitimate users and to administrators. Recovery may require physically visiting the affected hardware. Appropriate firewalls can block this attack. Classic Cisco IOS Software - ------------------------ Classic Cisco IOS software versions fall into three groups in terms of vulnerability. Highly vulnerable releases may hang indefinitely, requiring hardware resets, when attacked. Moderately vulnerable releases will not accept any new TCP connections for about 30 seconds after receiving an attack packet, but will recover and will continue to forward packets. Largely invulnerable releases will continue to operate normally with negligible performance impact. See the section "Affected Cisco IOS Software Versions" in this document for information on exactly which versions are affected. A configuration workaround for classic Cisco IOS software can prevent the problem entirely, subject to performance restrictions, for any version from 9.21 onward. Cisco has already released software fixes that protect some Cisco IOS software versions, and plans to release those fixes for other affected versions. Cisco IOS/700 Software and 7xx Systems - ------------------------------------ Cisco 7xx systems subjected to the attack will hang indefinitely and must be physically reset. A configuration workaround for Cisco IOS/700 software can prevent the problem entirely. Cisco plans to release a software fix for this problem. Cisco Catalyst LAN Switches - ------------------------- Cisco Catalyst switches subjected to the attack will hang indefinitely and must be reset. Not all Catalyst products have been tested, but this is definitely true of the Catalyst 5000 series, and is expected to be true of all Catalyst switches. The only workaround is to remove the IP address from the Catalyst switch, or to protect the switch by firewalling it using router access lists or dedicated firewall products. Cisco plans to release a software fix for this problem. Other Cisco Products ==================== Initial tests indicate that the PIX firewall is not vulnerable to this attack. Tests have been conducted with versions 4.1.3.245 and 4.0.7. Initial tests indicate that the Centri firewall (build 4.110) is not vulnerable to this attack with no exposed services configured. We have not yet tested the Centri product with exposed services. Cisco IOS Software Details ========================== Affected Cisco IOS Software Versions and Software Upgrades - -------------------------------------------------------- There are two bugs that make Cisco IOS software vulnerable to this attack. Fixes exist in the field for both bugs. Bug ID CSCdi71085 makes systems highly vulnerable to the attack. Bug ID CSCdi87533 makes systems moderately vulnerable. Bug ID CSCdj61324 is a newly-created bug ID that is being used as a tag for integration of the fix for CSCdi87533, plus a largely cosmetic change that prevents even the temporary creation of a half-open connection.The fix for CSCdj61324 has not yet been integrated into any released code, but is not necessary if the fix for CSCdi87533 is present. CSCdi71085 and CSCdj87533 divide Cisco IOS software versions into three vulnerability classes. Versions that do not have the fix for bug ID CSCdi71085 are highly vulnerable, and may hang indefinitely, requiring hardware resets, when attacked. This includes all releases before release 10.3, as well as early 10.3, 11.0, 11.1, and 11.2 versions. Versions in which CSCdi71085 has been fixed, but in which CSCdi87533 is still present, are moderately vulnerable to the attack. These versions will not accept any new TCP connections for about 30 seconds after any attack packet is received, but will not hang completely, will continue to forward packets without interruption, and will recover with no long-term effects. CSCdi87533 has thus far been fixed only in 11.2-based releases; the fix was integrated in 11.2(3.4), 11.2(3.4)F, and 11.2(3.4)P. Versions in which both CSCdi71085 and CSCdi87533 have been fixed are largely invulnerable to this attack. These versions will create half-open TCP connections upon receiving attack packets, but will continue to accept legitimate TCP connections, and will delete the half-open connections within about 30 seconds. The performance impact of such a half-open connection during its lifetime is believed to be negligible. Future versions in which CSCdj61324 has been fixed will be invulnerable to the attack, and will not create half-open connections in response to attack packets. We believe the security advantage of the CSCdj61324 fix over the CSCdj87533 fix to be negligible; CSCdj61324 is largely a placeholder to be used for integrating fixes in future non-11.2 releases. If you believe that there is any possibility of hostile attack against your system, and if you cannot protect yourself using the configuration workaround given above, we strongly recommend that you upgrade to a versions containing the fix for CSCdi71085, since the impact of CSCdi71085 under this attack is very high. The fix for CSCdi71085 is available for releases based on 10.3, 11.0, 11.1, and 11.2, and has been in the field for quite some time. Users of 11.2-based releases should upgrade to post-11.2(4) versions, thereby getting the fix for CSCdi87533 as well. Cisco intends to release fixes for CSCdj61324 (equivalent to CSCdi87533) on non-11.2 releases. The timetable for releasing these fixes has not yet been set. At the time of this writing, the following releases are recommended: First released versions with all existing fixes (*= fix for Recommended for most Base Release CSCdi87533) installations ------------ ------------------------------ -------------------- 10.3 10.3(16) 10.3(19a) 11.0 11.0(12), 11.0(12a)BT 11.0(17), 11.0(17)BT 11.1 11.1(7), 11.1(7)AA, 11.1(7)CA, 11.1(15), 11.1(15)AA, 11.1(9)IA 11.1(15)CA, 11.1(15)IA 11.2 11.2(4)*, 11.2(4)F*, 11.2 11.2(10), 11.2(9)P, 11.2(4)F1 Before 10.3 End of engineering 10.3(19a) As with any software upgrade, you should make sure your system configuration is supported by the new software before upgrading. It's especially important to make sure that your system has sufficient memory to support the new software. Upgrade planning assistance is available from Cisco's Worldwide Web site at http://www.cisco.com/. Workaround for Classic Cisco IOS Software - --------------------------------------- Classic Cisco IOS software users can use input access lists on their interfaces to prevent the attack packets from entering their TCP stacks. Input access lists are available in all Cisco IOS software versions from 9.21 onward. Using an input access list will prevent the attack entirely, but may have unacceptable performance impacts on heavily loaded high-end routers. Traffic will still be fast-switched, but higher-speed switching modes may be disabled by the use of the input access lists. Use care in deploying this workaround on heavily loaded routers. If you have no existing input access lists, create a new IP extended access list. Use a presently-unused number between 100 and 199. The access list must have an entry for each IP address configured on the system. Deny packets from each address to itself. For example: access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 If you have existing access lists, you'll need to merge the new entries in an appropriate way, generally at the top of the list. The access list should be applied incoming on all interfaces, so a fragment of a total router configuration might look like this: interface ethernet 0 ip address 1.2.3.4 255.255.255.0 ip access-group 101 in ! interface ethernet 1 ip address 5.6.7.8 ip access-group 101 in ! access-list 101 deny tcp 1.2.3.4 0.0.0.0 1.2.3.4 0.0.0.0 access-list 101 deny tcp 5.6.7.8 0.0.0.0 5.6.7.8 0.0.0.0 access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Cisco IOS/700 Software Details ============================== All Cisco IOS/700 software versions are vulnerable to this attack. Cisco plans to release a software fix. The time of release has not been set. Workaround for Cisco IOS/700 - -------------------------- Add the following configuration command to any profile that may be active when connected to a potentially hostile network: set ip filter tcp in source <7xx IP address> destination <7xx IP address> block This will completely protect the 7xx system. We believe that 7xx configurations in which this command has unacceptable performance or other impact are extremely rare if they exist at all. Cisco Catalyst LAN Switch Details ================================= Cisco Catalyst 5000 LAN switches are vulnerable to attack. Other Cisco Catalyst LAN switches are believed to be vulnerable. Cisco plans to release software fixes for the vulnerability. The time of release has not been set. The attack may be avoided by not assigning an IP address to the Catalyst switch. However, this has the effect of disabling all remote management. Depending on its location in the network, it may be possible to protect the switch with router access lists or dedicated firewalls. An example of an appropriate Cisco router access list entry for specifically protecting an individual switch would be: access-list 101 deny ip <switch-address> 0.0.0.0 <switch-address> 0.0.0.0 Note that this is not a complete access list. Other, more general filters are feasible. Using Cisco Products to Protect Other Systems ============================================= We do not believe that this attack can be used against systems behind our dedicated firewall products, the PIX and Centri firewalls, unless general-purpose tunnels have been enabled through the firewalls. Such configurations are not recommended and we believe them to be uncommon. Properly designed anti-spoofing access lists at border routers can be used to prevent the attack from entering a private network from the Internet. Use the access lists to filter out packets whose IP source addresses are on your internal net, but which are arriving from interfaces connected to the outside Internet. Exploitation and Public Announcements ===================================== Cisco has had multiple reports of this vulnerability. Most exploitation seems to be using the original program, which sends one packet at a time. Floods of invalid packets have not been reported. This issue has been widely discussed in a variety of Internet forums. Exploitation code is widely available to the public. Cisco first heard of this problem on the morning of Friday, November 21. Distribution of this Notice =========================== This notice is being sent to the following Internet mailing lists and newsgroups: * cisco(a)spot.colorado.edu * comp.dcom.sys.cisco * bugtraq(a)netspace.org * first-teams(a)first.org (includes CERT/CC) * nanog(a)merit.edu Updates will be sent to some or all of these, as appropriate. This notice will be posted in the "Field Notices" section of Cisco's Worldwide Web site, which can be found under "Technical Tips" in the "Service and Support" section. The URL will be http://www.cisco.com/warp/public/770/land-pub.shtml The copy on the Worldwide Web will be updated as appropriate. Cisco Security Procedures ========================= Please report security issues with Cisco products to security-alert(a)cisco.com. Revision History ================ Revision 1, 14:00, 21-NOV-1997 Initial revision Revision 2, 08:00 Add information about highly vulnerable 22-NOV-1997 IOS versions. Add detailed information about affected version numbers. Add specific bug IDs. Add upgrade recommendations. Add first information about Catalyst LAN switches. General editing and reformatting. This notice is copyright 1997 by Cisco Systems, Inc. This notice may be redistributed freely provided that redistributed copies are complete and unmodified, including all date and version information. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNHcosQyPsuGbHvEpAQH1NQf+OJAF/qMwaCSwYysR5qu36iZ3K04bAJ9r MsqAxdlY10yyN//L2P8Ntz3AYOtOih6EZKBYmmz/kyTp7zMr2J3ZCw01O5s2LfTX 1McIBV8kzf0kMYh4c+0rsjqS6jlXC0OakCNav6P+rO13nb+FTfhWoDOzcFCxr4sB 5gQqAClQyvWhempObDRpLE0gHKnLyyB4wWkhBDbA9tQz4TmTDfwRiIDeWAuuYY7k 87BqS5a7g7G2MZRmeiKIJV8F66USN4vSpAJxIdzXAyyUjxZBdv9B4BHCb9/LUvTM cHr06PppMDm4mNJAP3sedVtOnQHR/rEPuBMfKAE6xg8zyyNvG/B93w== =SKCo -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP for Personal Privacy 5.0 mQGhBDPvjDARBAD82RXM1EyVSEpL6mpDMyxI8Scc22yVqRYL+Ckv0SXHEPaZNIgQ blVx32jyfnmGIZeVYK2sDRTB6vXJt1k+R5HRRhTG7fB0f309gT/Zgmk64zC7L4nL Qp6fNEVJLfxRdrwXCOPfBf56Y8vKBFZSvwK4qLNHurMP2MVUuYfCl2UpHwCg/6Wz FTHW34HvDKgD+3k0ap0lMq8EAME9i5IEdwTnGO2zsyyc/gw6QKoSGNEkbGmciZuk AQTulVKQpYMv1jIm6Uy91HbsR0mUWxPzCBPCvJzvZOW0O+AJq4m/h1dQD2kdIHt+ nYAdfZjY26YUpB6gfFmQucGhH/o8GfhkmN6Lw21+gx4lctfia2/46poasCNo961y KyuQA/ID6qpHargBoOk2n/av9jV1Rox8vhYVGwQhmVpYVUMzdw8ldo3CejaqyW97 IyOU7tZo4WUzJ2Z3sG0DHdim+VoeDjb5hsd34MzoGL7KjRFGldbNr2H/DhmItLyz xJ5YXgMXNGy3IhfOjCwZsGhZ1eTddxbD7rb7+VN/ROhTpCSXtEdDaXNjbyBTeXN0 ZW1zIFByb2R1Y3QgU2VjdXJpdHkgSW5jaWRlbnQgUmVzcG9uc2UgVGVhbSA8cHNp cnRAY2lzY28uY29tPrRQQ2lzY28gU3lzdGVtcyBwcm9kdWN0IHNlY3VyaXR5IGlu Y2lkZW50L2J1ZyByZXBvcnRpbmcgPHNlY3VyaXR5LWFsZXJ0QGNpc2NvLmNvbT65 Ag0EM++MTxAIANfnEviV6GSqF/7SMetsaCkKUe/TmcEtoYRdE9ZorvLlruvSaFHM gXCg4SqyC689BJJBaKN2MTYIV0T3idlbHp4mXHDyU28tTEFenA9m4ER0PxEO/wIT I3XoOO7SCxUnxyvxPy8Jn9PYBHMpF+iWqUbzLsX4tZI7LJj73i0vi+5tGNaBBFu4 cD2UJis7lb/CSK7bb4RJ6lHYVWHtbcFApwSRheeusvN0YwKpPg5hy6gwaUSKtddJ DadcJcQ/G2I820onsqgYRfDncEBYuLavuu2h5CuR+Qz6jrwNUAX1f6UxC2WYY7ts p+wzQJ9VuTnKQEFPc6GIoiSSeyV3KibzVZ8AAgIIAKDBdTFi6kQSB1+x7XQgQ8SN L0HFjtr25TMJr/eeU6m1NkrtCVg3llA+lhTmpork6ZDu3GXp/IW02o246G57Z23p HU1VkEwjsWl1sdUY5QH+wIV6uZJubZW1TroDI86l0m7WeWC+mqQXn6GuvkX+YpF5 qU1OCY9Pnen6sWkYXiqE5LW3USyYxglTac8EQqcs3JYevV1/M6oTWXdMSEDV2/Bq d9g5qZBYQFkkftdW6YsJPMGgn2EIyu4kTyazk3UafH/yqemCbGX6S5j3krCoIMwf UpeOHPB1OxACLB0loA2cwCpq5p7WhXUCyRuqdXYN50NUrmKDo8+hsL/e89PofQWZ AQ0DM++M2AFtAQgA0rsqUAdCxqMH23R11iGtk2Zo6fI8vxPkllEOru5J/cd9dn2B wT4NTf/b9O4JruX8/R9uWlS3E6jYVJyN2Dpl39X7wUf77B8fsY/4zaUkjDU39Q2E t+pR7tElm0C8BvZVGkDelXzXqeCTQfu1vZHICy7cfsy/BMNlpn93OEz/jS4PPZs5 SORqjEL9wouw/44MvJ08rdc/OOr1eKkLcBfzMMtuMAxLI1OlA/hzY28h/pfhDhAP 7Jkm7R1gDyL9ALYX1xvixPp8q2hEQ3BUtCEfCTHAouqbKiQss5ntC9DDVGqzxlQT ijk4V1/Re+pbb4LX4JZDln3ztkcMj7Lhmx7xKQAFEbRHQ2lzY28gU3lzdGVtcyBQ cm9kdWN0IFNlY3VyaXR5IEluY2lkZW50IFJlc3BvbnNlIFRlYW0gPHBzaXJ0QGNp c2NvLmNvbT6JARUDBRAz74zYDI+y4Zse8SkBAWVjCACT3Ia+8fVGzPd1ACBvMFGI Dry7lhhf9vz+flpOu3ErVn0qW2N0ONxT+u/Z+qbCGxz1DYlgTWt7+KJRS7FNNdzE J2ct9nvnDo/u/VdoTwdtpe9RtiYW4rG+HMjqCdnc5YSpVD8/VEHvPNLAe28wA6au S3L68XPyDjfa0N5T9YSJ/Q8B41qyxWMgETeZIVyegX0/BHv73zegsj5BRPP4pnem juvsRMVcFqJ7wxjm8yjZrR2zoZSysxWkWInbOu5IIlAm9VWh71VP2mD3Z8fDq9Jh kF/qNw937eRSMBwBlCPkmS6jlC0Nz4mkKzoDglL6eTZQ9iKwU5/EeNHZu/f3rKaV iQA/AwUQM++M9JaBp3w9UuB/EQLzmwCgtbsVjd1ZZcuJkPoVs3cbzX9JibYAoLcQ 8+WP7M0y3zdSUEhHToFY6E+ZiQA/AwUQM++N6GFYFsU6zlX+EQKEywCggc3awk02 yj6RivcbYFn3Qon77scAn29CR0lHAjsdLIv6LJ9BLdhXiK8piQCVAwUQM++6KXem vD4nAHb9AQG6OQQAq/GzwDk4yT9MPy25AwBMgsPGePRkZ6kBXTBsmMnHxthDniyE Xqvg6XJYRU86f2wyfzVDJY55qmukl9haCqe3Inxo7gyHaB8ji4rMqfmEn2fjbiAv dw5wlQqYBEEYWAviAHpBlTqT7naq5u/TyAdgENROnFu1jLT39uJ4RPpO7o2JAHUD BRAz8OcoAFBd0vcu1XkBAQHWAwCe0KmW5QKgf1Kmf7hEEpBT2pViNkv3J7tB33Py 4ohQYztUUwP8QJq9EQR3qCBgUJfa3VhXWPrzTn6hE7H/GHEJ7g5IbY9fo1DHcxyE xaBBKIEoWKR/FdxsNPBTgcaT9TyJAJUDBRAz8OTdGKb4qo5nGiEBAU7QA/4+RFkA yy4YnrZc6Y7btnCgHXIwH4tqFL3NaVVS4KsGzQ2WgLRRz1rJ3D61aqvk9Tz3vY5m YwjWY+eOwBqjuEl5UUQqY2kn6c8XHnp+Y7XfwPqH7V5hixcwSTHgU0diav+E/1FP sm6oUKEHh4cC0vfsYOjqlSoilF1sjqKZT5MZZIkAlQMFEDPw6Yx61S0GnPSVuQEB meoD/1VyOvmqnEQsTBiYmEGKHgSFrRs95vEOlP/ANCVYXwpBVP51Vrj+RcNkNJAQ 5xX5D5nRgDGoUVpYcjUJivalH6MOrPHF2zG/As9onZira+dv9SjM/MJhdpGvx0oT YtpGlQh79+uloqCAZ9P4c/flZZICRLjI/3Uj73HDbEAcLsX8iQA/AwUQM/DxS7iw R2HEkUMHEQJK7gCfRWzVa9mGDX4X2BdUB1Z5l5DCM+MAn2SIHiZS3o94TVhp+jTL 2HWHbnPjiQCVAwUQM/DpqtRZvFG/tj1hAQGsZgP8DJgX+4foQlVnDD+gBKXmnG3Z D1hHkpvrR/tGww6LjxKAhXSWtQKTysQ3seIQyUxLOOq0K4A9vFzzmW1gDZXwYwG7 PXoNn4uyGY3YF2jke+Unug41F9POcBp4pUfjQxgj7iiPRn6ZduEhPjw6RBRpYDH5 fF3Mu5/E01TygWisn8WJARUDBRAz81dfH2q6+RwPtwkBAcNnCACSHlH85LxLMRVY 46WdQ9Joj8809J4p0Q469Tkrq7wMyxv8znvvl+D2loIaL5SeBGIvfFaPKQnN+un3 gX/R3g+l2RxBQRqjr65kGAhsMr1L9bRsMAUKAKfDLbQk9fEmB2KRBvQYsHM/7fVY eXglIxdO40AUnzPtRz9rYlZ7dBn7Dy5k/kjIBKKZhgu77X0fGjh9hP9s45D3vnNq sKBoM7pvgdTrwYbdarK2a4GPpWm7XHkhr1w2nGA+a0zjCDzfObHTp8NMY3z0Rgeu 3t2W7EIF6zE+FSyZmfTvVd2rXMxgjMeeziPHAJESnmQ0y0+xQoDx1IDhQ7YF2Q6r khfqxxM6iQA/AwUQM/KsxSLcSmI6S/dwEQKA0QCfR1O0vDQ0M8ef9c+DHPyNydGz OOQAnRscGYHbrrXrN1yuA9mti29pz2BViQCVAwUQM/EQTX+11HSaYdsJAQE7ZgQA 8Z5GzK1Qd4vu1Rt0OAubPp9yug2QmTqyNAsDDQdiqcdvCF9cK8VCYBvTRaHDjFBx Jd6PclQlLBcPIQnkCE4Pch1OQomckDzXEnNgleGnyQlMXT0zm+gHl5mDUWnRtwTD drYxfLdJZFZ8ntJIDYN7t0Gl/ag5l4j0C5GW0d9WYo+0UENpc2NvIFN5c3RlbXMg cHJvZHVjdCBzZWN1cml0eSBpbmNpZGVudC9idWcgcmVwb3J0aW5nIDxzZWN1cml0 eS1hbGVydEBjaXNjby5jb20+iQEVAwUQM++NXQyPsuGbHvEpAQEIKwf/eLwnERXH CP4X999/aUJEMPzd8lMaFg1i84ALFhpFKzWHBnWkBZItTM35xzciq5v51P3OBu5u scU/yRgHmg/ESH3abJXt3SKMsjzZE1zvKuqX0wjYf3Ihh2CtPZo/3wpsa6XGuLdT 0dDUCdU8Tjd67wX3p+CI6CBGoMqLuVY/0AO9xoo7drVoOT9fYQ7UjSNIkxN9nVzI yWmaudOzeLnHaVf7jYYeOmADe1YaVM3oMVZrmTZ1TtPMTd0ovWrPll27zVYx1PjE NuTZDpnysa7agoD5hemtKUXR0GwbeoVMpIWCceKNNPh8kjb6B5sTOl7y8ZR/gUld CaNn5sbZ1N1QrIkAPwMFEDPvjXSWgad8PVLgfxECp2MAn1VUzoaLFiek6lky++m4 qTc4ejAoAJ9DE/8NyaqDkq0M+d3qEcxpVsQEBokAPwMFEDPvjflhWBbFOs5V/hEC GTAAoNaAhsFpD+qhH0X8IyGaljO1ywwHAKDYNOETuHePkca+yLDLwyxlmYurmYkA lQMFEDPvuil3prw+JwB2/QEBcpsD/25lxJqT+7jW4W6jDm7CTJ2OR8fPtdEUrj0d fujPCgltXJ3OVREwg69vCl/rCz9sVPKEzVFEbdvkTmjimxeg1ajBcb642SZMuFcg E60fhNyNsteyktZSI20E2UnZ0MrGK33J7Vn/1xPCl9o3ICa1vRo8E3ixnyvoGaB3 jhXHSdIviQCVAwUQM/Dk6him+KqOZxohAQEn9QQAtd5uSls7cYT+MZvjWrMxyhNV e3eSqHWZjXImWg8SWVey0/XI7ze5zMt8+GEpQoAaD9ZlLl4WthNG8iq7YdnsXQ99 OqpF4pRSvsYVv5BRPO3XvwNDN8jJMdP7jcIgwXo08Zt1YWTDMxpSNcF7ARfZ5M2D V9FKhgLris+9IRcWeemJAJUDBRAz8OmTetUtBpz0lbkBAdxmBACq97OI8lyJWvN1 qeZQca3wtrauXWpehi1gBxLnWBUPYPGV78nVIi/JFbKxMTT6zxf7ODDvXNBebngp Qp2gVO8TJ6tzrk2dVUKA9Sk03z8fRdSk13WhnYoojPPebFBtXBrnSxEq9gEVSj2Z R9u/5qUUrjKtZqoAXcPHfwqJCuo5rYkAPwMFEDPw8fC4sEdhxJFDBxEC75sAmgMQ NrF121TfmZ6QKCU2NscuY5H6AKCJinLR8Hwm00kTSTfFAO5bQfy4bYkAlQMFEDPw 6bfUWbxRv7Y9YQEBJtkD/3BgNhOa+2hK68jTI4hMaCaHyRII4wCZeKSEjoBJnLwa GQ9fs5jbJtfYjDtdcCkvSZy4OvXcWb7Gu31PKbJgBtGeY+Ns+fUahhUz+is35H+3 +ZuV91v56SW8wqcKEDt40V9g1TP5X6VE+QfXnoScFdjCbOViwoR6saPEkujJASuy iQA/AwUQM/Ks2CLcSmI6S/dwEQKghwCeOY2rw3OcrQdiDCJxZhSMMCa17pAAoIrq 3Epb5UdZEnZxJ/aZpGR/ROaaiQCVAwUQM/EQdH+11HSaYdsJAQGKBAP+LRkDVCwW NCpAAFOag6ou3SmFfxD19qRfLPbjlm3nLk6wYvbSXBVp1VXMRJkdmCXSxMe0vo1r xCMoL66qVutyHrSgifPPN6AYNPKTTNUx5o0Ck5xXf4PWoy8cfvyrKJtd/wDi4Ryf WOsZNYKVAf1ItbZse243ICsgMAduzZLgygo= =OrTt -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Land and Cisco
by Hank Nussbacher 22 Nov '97

22 Nov '97

Ignore my last posting - brain check. -Hank

1 0

AT&T Emergency 24hr Contact
by Adam Alexander 22 Nov '97

22 Nov '97

Does anyone have an AT&T 24 hour phone line for emergencies regarding internet services or dealing with their NOC? Adam Alexander yacko(a)dal.net, yacko(a)home.net, yacko(a)neXusNET.org ------------------ Network Administrator of neXus Networks DALnet IRC Operator - qis.md.us.dal.net

2 1

Sprintlink problems?
by Turnando Fuad 22 Nov '97

22 Nov '97

Our 206.107.208.0/20 netblock have been dampened numerous times today. Anyone know why Sprint is announcing the /14? BGP routing table entry for 206.104.0.0/14, version 5323768 Paths: (2 available, best #1, advertised over IBGP, EBGP) 1239 198.32.136.11 from 198.32.136.11 (144.228.105.1) Origin IGP, metric 5, localpref 100, valid, external, best Community: 2548:668 1239 198.32.136.129 from 198.32.136.129 (144.228.105.5) Origin IGP, metric 28, localpref 100, valid, external Community: 2548:668 Regards, Turnando Fuad NSNet

2 2

Re: "LAND" Attack Update (fwd)
by Mark Milhollan 22 Nov '97

22 Nov '97

>is SYN a TCP small service? SYN is what initiates a TCP session. All TCP listeners are at risk, i.e., tcp-small-servers, vty's, rcmd's, some routing protocols.

1 0

Re: "LAND" Attack Update (fwd)
by Joe Shaw 22 Nov '97

22 Nov '97

>BugTraq has a note that version 10.3(7) is vunerable. I don't know which >version of Cisco the IOS was running on. > >-- >Stan | Academ Consulting Services |internet: sob(a)academ.com >Olan | For more info on academ, see this |uucp: >{mcsun|amdahl}!academ!sob >Barber | URL- http://www.academ.com/academ |Opinions expressed are only >mine.A Here's the post from bugtraq that details which operating systems and what hardware/software versions of Cisco IOS are vulnerable. I'm wondering, is SYN a TCP small service? I could usually find this out for myself, but my 102 degree fever is making it hard to think. Back to bed with me, Joe Shaw - jshaw(a)insync.net NetAdmin - Insync Internet Services ---------- Forwarded message ---------- Date: Fri, 21 Nov 1997 13:22:22 -0600 From: Aleph One <aleph1(a)dfw.net> To: BUGTRAQ(a)NETSPACE.ORG Subject: Re: "LAND" Attack Update The latest update. It seems that not many versions of IOS are affected. The symptoms can also be strange. It will stop accepting connection, then after 30 seconds if may stop accepting processing ICMP echos, and after that it stops forwarding packets. So if you perform the test wait a couple of minutes and see if it still up before you come to any conclusions. Ivan Ganev also reports that testing again port 23 alone would not kill the router but testing againts the first 255 ports did. >From the reports is seem to be the older revisions of IOS (10.X and 11.0) in certain hardware configurations and the Cisco 700 Series ISDN access routers (not running IOS) are vulnerable. We keep getting conflicting reports for FreeBSD and OpenBSD. The are enough reports and indications that those operating systems are indeed vulnerable but the vulnerabilitiy may not show up in all configurations depending on the enviroment, the intensity of cosmic rays, the phase of the moon, and if the testing person is left or right handed. An external "land" attack should not be an issue if you are filtering IP address spoofing at your ingress routers. You _ARE_ doing so? Correct? Well in case you forgot you can find Paul Ferguson's "Network Ingress Filtering: Defeating Denial of Service Address Spoofing" Internet Draft at ftp://ietf.org/internet-drafts/draft-ferguson-ingress-filtering-03.txt I highly recommend you implement it's recommendations. Of curse you are still at the mercy of those behind the filter. The survey says: AIX 3 IS vulnerable AIX 3.2 NOT vulnerable AIX 4 NOT vulnerable AIX 4.1 NOT vulnerable BeOS Preview Release 2 PowerMac IS vulnerable BSDI 2.1 (vanilla) IS vulnerable BSDI 2.1 (K210-021,K210-022,K210-024) NOT vulnerable BSDI 3.0 NOT vulnerable DG/UX R4.12 NOT vulnerable Digital UNIX 4.0 NOT vulnerable FreeBSD 2.2.2-RELEASE (confilcting reports) FreeBSD 2.2.5-RELEASE (conflicting reports) FreeBSD 2.2.5-STABLE (conflicting reports) FreeBSD 3.0-CURRENT IS vulnerable HP External JetDirect Print Servers IS vulnerable HP-UX 10.20 IS vulnerable IRIX 5.3 IS vulnerable IRIX 6.2 NOT vulnerable IRIX 6.3 NOT vulnerable IRIX 6.4 NOT vulnerable Linux 2.0.30 NOT vulnerable Linux 2.0.32 NOT vulnerable MacOS 7.5.1 NOT vulnerable MacOS 8.0 IS vulnerable (TCP/IP stack crashed) MVS OS390 1.3 NOT vulnerable AIX 4.1 NOT vulnerable NetApp NFS server 4.3 IS vulnerable NetBSD 1.1 IS vulnerable NetBSD 1.2 IS vulnerable NetBSD 1.2a IS vulnerable NetBSD 1.2.1 IS vulnerable NetBSD 1.3_ALPHA IS vulnerable NeXTSTEP 3.0 IS vulnerable NeXTSTEp 3.1 IS vulnerable Novell 4.11 NOT vulnerable OpenBSD 2.1 (conflicting reports) OS/2 3.0 NOT vulnerable QNX 4.24 IS vulnerable OpenBSD 2.2 (Oct31) NOT vulnerable SCO OpenServer 5.0.4 NOT vulnerable Salaris 2.4 NOT vulnerable Solaris 2.5.1 NOT vulnerable Solaris 2.6 NOT vulnerable SunOS 4.1.4 IS vulnerable Ultrix ??? NOT vulnerable Windows 95 (vanilla) IS vulnerable Windows 95 + Winsock 2 + VIPUPD.EXE IS vulnerable Windows NT (vanilla) IS vulnerable Windows NT + SP3 IS vulnerable Windows NT + SP3 + simptcp-fix IS vulnerable Some misc stuff: 3Com SuperStack II IS vulnerable Apple LaserWriter IS vulnerable Ascend 4000 5.0Ap20 NOT vulnerable Ascend Pipeline 50 rev 5.0Ai16 NOT vulnerable Ascend Pipeline 50 rev 5.0Ap13 NOT vulnerable BayNetworks MARLIN 1000 OS (0).3.024(R) NOT vulnerable BinTec BIANCA/BRICK-XS 4.6.1 router IS vulnerable Cisco IOS 10.3(7) IS vulnerable Cisco IOS 11.1(13) NOT vulnerable Cisco 1003 IOS 11.0 NOT vulnerable Cisco 1005 IOS 11.0(4) NOT vulnerable Cisco 1600 IOS 11.0(6) fc1 IS vulnerable Cisco 1601 IOS 11.1(8) AA NOT vulnerable Cisco 1601 IOS 11.1(10)AA NOT vulnerable Cisco 2500 IOS 11.0(9) NOT vulnerable Cisco 2500 IOS 11.1(6) fc1 IS vulnerable Cisco 2500 IOS 11.1(10) NOT vulnerable Cisco 2501 IOS 10.2 IS vulnerable Cisco 2501 IOS 10.2(2) IS vulnerable Cisco 2501 IOS 10.(7) IS vulnerable Cisco 2501 IOS 11.1(9) NOT vulnerable Cisco 2501 IOS 11.2(4)P NOT vulnerable Cisco 2503 IOS 11.0(9) IS vulnerable Cisco 2509 IOS 11.1 NOT vulnerable Cisco 2511 IOS ??? IS vulnerable Cisco 2511 IOS 10.3(4) NOT vulnerable Cisco 2511 IOS 11.1(8) NOT vulnerable Cisco 2511 IOS 11.2(4) NOT vulnerable Cisco 2514 IOS 11.2(5) NOT vulnerable Cisco 3102 IOS 9.X IS vulnerable Cisco 4000 IOS 11.0(7) NOT vulnerable Cisco 4000 IOS 11.1(6) NOT vulnerable Cisco 4000 IOS 11.2(4) fc1 NOT vulnerable Cisco 4000 IOS 11.2(9) NOT vulnerable Cisco 4500 IOS 10.13(15) IS vulnerable Cisco 4500 IOS 11.2(9) NOT vulnerable Cisco 4700M IOS 11.0(16) NOT vulnerable Cisco 7000 IOS 11.0(1) NOT vulnerable Cisco 7000 IOS 11.0(16) NOT vulnerable Cisco 7000 IOS 11.1(12) NOT vulnerable Cisco 7000 IOS 11.2(8) NOT vulnerable Cisco 7507 IOS 11.0(17) NOT vulnerable Cisco 753 OS Release 4 IS vulnerable Cisco 753 OS Release 4.0 IS vulnerable Cisco 754 OS Release 4.1 IS vulnerable Cisco 761 OS Release 4.0(1) IS vulnerable Cisco Catalyst 5000 IS vulnerable Digital VT1200 IS vulnerable HP Envizex Terminal IS vulnerable LaserJet Printer NOT vulnerable Livingston Office Router (ISDN) IS vulnerable Livingston PM ComOS 3.3.3 NOT vulnerable Livingston PM ComOS 3.5b17 + 3.7.2 NOT vulnerable Livingston PM ComOS 3.7L NOT vulnerable Livingston Enterprise PM 3.4 2L NOT vulnerable Milkyway Firewall 3.02 (SunOS) IS vulnerable NCD X Terminals, NCDWare v3.1.0 IS vulnerable NCD X Terminals, NCDWare v3.2.1 IS vulnerable

1 0

Land Protection for Cisco
by Ken Harris 22 Nov '97

22 Nov '97

snippet from bugtraq: ---- hi. Here is a simple protection against the land stuff for the cisco's. It's a extended ip access list that should be put on all the intefaces on the box. Extended IP Access list 105 deny tcp host 111.111.111.111 host 111.111.111.111 permit ip any any where 111.111.111.111 is the interface's ip address. This should be put as an input access-group. Or if you don't get it here's what to type on your cisco's console. rtr#config terminal rtr(config)#access-list 105 deny tcp 111.111.111.111 0.0.0.0 111.111.111.111 0.0.0.0 rtr(config)#access-list 105 permit ip any any rtr(config)#interface ethernet 0 rtr(config)#ip access-group 105 in rtr(config)#exit rtr(config)#interface serial 0 rtr(config)#ip access-group 105 in and so on for the rest of the interfaces... Replace 105 with a free extended access-list number. I have tested it on our cisco 2511 and it works just ok. - -- --------- Ken Harris [( ken(a)drummerweb.com )] Drummer Associates [( www.drummerweb.com )] "Education is what remains after one has forgotten everything learned in school" -Albert Einstein - -- ---------

3 2

more keynotification
by k claffy 21 Nov '97

21 Nov '97

(see www.keynote.com) there seem to be some, uh, `interest' in keynote info last time it came up so just fyi (i.e., does not consititute endorsement or dismissal of content) [randy, why don't we just meet at ietf so you can main me in person for posting this rather than wasting nanog b/w on it] k ----------------------------------------------------------------- Backbones Wheel and Deal to Keep Net Moving by Gene Koprowski Some Internet wags claim that the initials WWW actually stand for "World Wide Wait." And according to a recent study, they might be more right than ever. Research being released by San Mateo, California-based Keynote Systems Inc. indicates that the technical performance of the Web has "degraded" by 4.5 percent since spring. Congestion at access points like MAE East and MAE West is so severe that in order to maintain acceptable performance, Internet backbone providers are continually having to monitor the traffic of the Net and change their routing assignments through new peering agreements, says Gene Shklar, vice president of Keynote, a diagnostic services consultancy that works with Web hosting companies. Despite claims of "increased bandwidth" advertised by many Internet backbone providers, performance is not keeping up with perception or demand. In fact, the average speed that content was traveling on the Internet, as of September, was just 5,000 characters per second, or only 40 Kbps. So cable modems, satellite modems, and other fast-transit technologies are not performing as advertised most of the time, and regional routing infrastructure disparities have a lot to do with that. Cities like Atlanta, Miami, and Dallas are suffering from slower access than San Francisco or Boston, Shklar says. The Keynote Systems' report was based on tests that used dedicated workstations for 45 days - once every 15 minutes - to determine the backbone network speeds. "The study is based on millions of measurements of what matters most to Web sites, which is how long it takes them to deliver content to their end users," says Shklar. "If you have to commute to work each day, it doesn't matter how well-engineered the road you are driving on is. What matters is how long it takes you to get to your destination." Most of the performance problems are out in the network, not on the individual Web sites. The problems tend to occur just as they do in the highway system: at the on-ramps and off-ramps. If the US had one homogeneous Internet network, the system would work quite flawlessly. But, Shklar notes, there are 47 different Internet backbone providers in America alone and 4,300 ISPs. "Any kind of average Web transaction from server to user ends up crossing at least three transit points," he says. "Each of the backbone providers is very good at running their own network. But they don't care at all about making optimal routing decisions based on the performance that the users will get." The report indicated that Internet backbone provider Savvis Corp., based in St. Louis, Missouri, had the fastest average page download time of all major providers. The time was 4.905 seconds per page. The runner-up was Cable & Wireless with a 5.008 average, followed by CompuServe (5.664) and UUNET (5.912). AT&T, by comparison, ranked 15th with 8.559 seconds for an average download, and Netcom came in at 31, with a time of 15.181 seconds for a page download, Keynote indicated. Overall, 34 backbone purveyors were surveyed. Savvis president and CEO Sam Sanderson said that the report - which will be published in Boardwatch magazine on Friday - indicated that Internet backbone providers would have to continue to purchase connections to large networks rather than peer at public network access points in order to maintain their level of service. "We're going to continue that strategy," Sanderson says. Brian Robertson, chief technical officer at PlanetAll, a Web site that helps friends locate missing pals and colleagues over the Internet, said the report was "interesting" and he agrees that the private network concept is going to continue so that electronic commerce will be able to flourish. "There are a lot of times when a site looks like it is down on the Web, but if you ping it from another location, it is OK," says Robertson. "The idea is to keep the traffic off the Internet and avoid the big switches, like MAE East and MAE West. If you have a bunch of redundant connections, get the packet of data off the Internet onto a separate network, run it through a SONET ring to the next closest data center. You generally try to minimize the number of hops of data across the network. That kind of service will have to continue for Web commerce to survive."

3 3

Re: whois.internic.net
by Gerald Andrew Winters 21 Nov '97

21 Nov '97

Hi William, try: whois -h rs.internic.net as1234 Schickentanz, Alfred (AS1234) alfred(a)WELL.COM Immortality Systems 13 Main Dock Sausalito, CA 94965 (415) 332-1266 [snip...] or you're welcome to try our server for internet routing information: whois -h whois.ra.net as4557 aut-num: AS4557 as-name: TEXAS-GIGAPOP descr: Texas GigaPOP AS as-in: from AS145 10 accept ANY AND NOT {0.0.0.0/0} as-in: from AS8 10 accept AS8 as-in: from AS7276 10 accept AS7276 as-out: to AS145 announce AS-TEXASGIGAPOP as-out: to AS8 announce ALL as-out: to AS7276 announce ALL admin-c: FG50 tech-c: SB98 notify: sob(a)academ.com mnt-by: MAINT-AS4557 changed: sob(a)academ.com 971114 source: RADB --Gerald (merit)

2 1

Re: Geographic v. topological address allocation
by Sean Doran 21 Nov '97

21 Nov '97

"Kent W. England" <kwe(a)geo.net> writes: > This is true, but the definition of the top of the hierarchy is arbitrary > and is the nexus of the debate about "topological" versus geographical > addressing, which I interpret as "ISP at top" versus "exchange point at > top" hierarchies. Both are valid topological hierarchies. As tli pointed out the top of the hierarchy is not arbitrary, it must be default free. In a hierarchical routing system there are three forwarding directions to consider: intra-area ("lateral"), default ("upwards") and sub-area ("aggregate" or "downwards"). At the top of a hierarchy you cannot have an upwards forwarding direction, therefore the entire address space must be intra-area or presented as an aggreagate. If you consider an addressing structure that looks like this: level-3-area-id:level-2-area-id:level-1-area-id:final-flat-id and in an internetwork with three levels of hierarchy, this pattern is easy to consider. A level-2 router may have some things directly attached to its level-2 area, including its peer routers, and it would carry routes towards them, which probably would be in a flat routing table. Among the reasons it needs these routes is that it has to know where to send traffic towards each of the level-1 areas that are attached to its own area, and it has to know where to send "default" traffic towards one or more of its in-area peers that have level-3 connections. Each such level-3 router would have to know how to foward to any given level-2 area, and therefore would need to carry routes for each level-3/level-2 gateway. Each level-1 router, by contrast, only needs to know how to route towards all the things in its area, and how to reach at least one level-2 router. (One can be a little tricky and have a single level-1 area connected to multiple level-2 routers in different level-2 areas, in which case better routing optimality may be obtained by the level-1 router carrying some level-2 routing information. This would be analogous to Yakov Rekhter's "route pull".) However, the minimum set of routes to carry is that which can cause traffic to be forwarded along a strict single-path tree-like hierarchy. This requires that each area be fully contiguous at all times. Other routes may be introduced in various places to alter this behaviour if that is desirable, or to effect IS-IS style partition repair. In order for the hierarchical routing system to scale the number of entities known in any given area must be small enough to route on in what is conceptually a flat manner. That means that there are bounds on the number of level-n to level-n-minus-one areas, and this in turn requires that the addressing scheme allow for a deep enough hierarchy. Consequently, the number of things in the top, default-free hierarchy is always going to be limited, no matter what "type" of hierarchical allocation scheme is proposed. The further requirement that any given area be fully contiguous means that the "top" of the hierarchy must be self-repairing. In other words, as tli pointed out, if you have a switch in some convenient geographical location, like the Grenwich Observatory or the UN building or MAE-EAST, your entire routing system fails if that switch or that location fails. Consequently, to avoid the single point of failure, there would be a desire to have several diverse geographical locations to act as the top of the hierarchy. The problem, again, is that any given area must be fully contiguous, and this implies that any level-n router connecting to one of these diverse locations would have connectivity to every other level-n router, so that this top level n area would be contiguous. One could propose to implement this as a big bridged network. The original DGIX proposal was along these lines. Operational experience with much smaller but still big bridged exchange points has demonstrated pretty much conclusively that this is a Really Really Bad Idea. One could propose to implement this using the native protocol, effectively connecting all of these exchange points into a level-n-plus-one area of its own. As long as the level-n-plus-one area could route to all the level-n areas at all times, this would work just nicely, on a technical basis. The difference therefore between your "ISP at top" option and your "exchange point at top" option is that in a hierarchical addressing system, which is the only way we currently know how to scale a global internetwork, is merely in the choice of words. Whatever is at the top has to connect reliably and continuously all the things that are one step down from the top, and simple belt-and-suspenders implies geographical diversity. Thus, the top of the hierarchy may be expressed as a big, geographically diverse bridged network connecting all the "next-level-down" routers, a single big geographically diverse routed network comprising a single area, or a meshed concatenation of the "next-level-down" routers in such a way that robust interconnectivity among them is maintained at all times. The choice is probably best made on the basis of reliability and cost, but experience shows that it is likelier made on the basis of politics, autonomy/mistrust of other operators, marketing goals, and possibly cost. If it were possible for two routing areas to cleanly synthesize a next-level-up area, which probably implies the use of variable length addresses, then it strikes me intuitively that better routing hierarchy than is likely to be cobbled together through the deployment of physical infrastructure can be enjoyed, keeping the number of routing entries needed by any given router anywhere in such an Internet to a minimum. With a variable length addressing scheme, in other words, one can consider a set of operations which can be summarized as "make-hierarchical" or "make-lateral". The obvious and increasingly important first baby step in an evolutionary path towards a scalable Internet is, to quote Noel Chiappa, "to make the world safe for NAT, by making all end-to-end functions use the DNS name; e.g. for authentication, pseudo-headers for checksums, etc, etc." As he continued, this can be justified solely on the basis of working better with NAT, which solves some real-world problems now, and which is being used now. There is lots more to discuss. Is big-internet still in post-Bass trauma? If not, let's discuss it there, or privately. However, to tie in some tiny degree of NANOG relevance, and to emphasise through repetition, the idea of using a large bridged network has been broken through the history of exchange points, particularly since the lovely days when people didn't learn from Milo's FIX upgrade path and began doing multimedia bridging. Single exchange points fail, so avoiding the large briged network by having a single exchange point be the "top" of a hierarchy won't work. Therefore, the current hierarchy implemented in provider-based addressing with some coordination to preserve some degree of geographic alignment of addresses (through ARIN, RIPE and APNIC, and large-ISP allocation strategies), is almost certainly the most appropriate one. That is to say, we got CIDR pretty much right. Sean.

2 1