- Test - lists.nanog.org

Re: Agenda suggestions?
by Vadim Antonov 26 Jan '95

26 Jan '95

>I would say that it's better to have the route go away and let the user >know about it than to throw data into the bit bucket. Static routes shouldn't go away. It was a cheap shot to help people who can't configure dynamic routing properly. >Maybe we could compromise on an option to leave the route there when the >circuit goes down, It has to be default to take any effect on global routing flap. Non-default options aren't used by those without a clue; and it is precisely netadmins whith no clue whose networks do most harm to the Internet. >for those network managers who want to receive calls >from users saying "My data went into the bit bucket" and then spend some >time to figure out that it's because the circuit went down. Those "managers" got to fix their routing, ok? --vadim

1 0

Re: Agenda suggestions?
by Vadim Antonov 25 Jan '95

25 Jan '95

smd> This dovetails into the new religion that doing BGP or other smd> dynamic routing with singly-homed customers is a bad idea, smd> even for policy or political reasons. Hm. If it a new religion, will you nominate me for the Prophet? :-) Another thing we really need from router manufacturers is _persistent_ static routes by default. The current behaviour of one rather popular brand of routers (name witheld to protect the guilty) is to remove routes if the associated circuit goes down. We need to change it to have packets to go to the bit bucket instead, and make the old behaviour be configurable with an explicit knob. --vadim

1 0

Re: Agenda suggestions?
by Sean Doran 25 Jan '95

25 Jan '95

| >Routing flaps considered harmful... | A while ago Curtis proposed a scheme for holddowns that | has a property that a holddown time associated with | a route increases with the frequency of this route | flapping -- so that frequently flapping routes getting | progressively long timeouts. This is a good idea, if a bit of a gross and ugly hack at one aspect of the problem (frequent flaps of one specific set of prefixes). There are also ways of helping out right now that aren't dependent on implementation changes to router software and are better general fixes for the sheer number of flaps, imho. Part of what needs doing is a decision about what should give a host unreachable/network unreachable message. Right now it tends to be a box very close to the originator; I would tend to argue that this is no longer necessarily a good idea, and that in the case of statically-routed single-homed internets a box as close as possible to the destination could do that job just as well (with side effects like fewer globally-visible route-flaps). This dovetails into the new religion that doing BGP or other dynamic routing with singly-homed customers is a bad idea, even for policy or political reasons. If it's *really* necessary to do this (people argue that, among other reasons, this is something that should be done so that the CIX router can distinguish CIX member routes from non-CIX-member routes belonging to non-CIX-member resellers), it probably would be better to route them statically and advertise a lie saying that the routes originated in e.g. BGP or EGP with AS XXXX. Sean.

2 1

Agenda suggestions?
by yakov＠watson.ibm.com 25 Jan '95

25 Jan '95

Ref: Your note of Wed, 25 Jan 1995 05:57:53 -0500 >Routing flaps considered harmful... A while ago Curtis proposed a scheme for holddowns that has a property that a holddown time associated with a route increases with the frequency of this route flapping -- so that frequently flapping routes getting progressively long timeouts. Yakov.

2 1

Agenda suggestions?
by epg＠merit.edu 25 Jan '95

25 Jan '95

We are in the process of putting together the agenda for the Feb 9-10 meeting of NANOG. Does anyone have any topics which they would like to see on the agenda? Some suggestions that we have had are: 1) status of the transition to the new NSF Architecture 2) technical presentation on what is a route server 3) discussion on cooperatively rationalizing MBONE routing 4) IPv6 transition 5) end-to-end problem resolution - is it possible? 6) RADB - how to use it 7) ATM testbed results Please send those cards and letters soon - otherwise we'll just have to make up something. --Elise

4 3

Additions to the NSFNET policy-based routing database
by smm＠twain.merit.edu 23 Jan '95

23 Jan '95

------------------------------------------------------------------------------ The PRDB and this "NWG report" will be retired very soon. Details below. ------------------------------------------------------------------------------ The following changes have been made to the NSFNET policy-based routing database and will be installed on the backbone by 08:00 EST : Total = As + Bs + Cs + Aggs Registered Networks 45617 = 30 5241 37855 2491 Configured Networks 42580 = 30 5184 34939 2427 Added Networks 144 = 0 4 128 12 Deleted Networks 2 = 0 1 0 1 IP address Net name Country Priority:AS ---------- -------- ------- ----------- 146.243/16 MASS-GOV-NET C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 152.104/16 HONGKONG-NET C:HK 1:1321 156.8/16 ISCOR-VDB C:ZA 1:1800 2:1240 3:1239 157.200/16 FINNAIR-NET C:FI 1:701(136) 2:701(134) 3:1800 192.17.5/24 INTERTV-DOM C:US 1:3830 2:1800 4:1240 192.22.10/23 APPLICON C:US 1:1225(130) 2:1225(129) 192.22.12/22 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.16/23 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.30/23 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.32/23 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.40/24 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.22.50/24 APPLICON C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.58.172/24 LOCKHEED-ESC C:US 1:1332 2:1321 192.68.118/24 PGE-CNET-C-68-118 C:US 1:2149 2:174 192.68.119/24 PGE-CNET-C-68-119 C:US 1:2149 2:174 192.68.120/24 PGE-CNET-C-68-120 C:US 1:2149 2:174 192.68.121/24 PGE-CNET-C-68-121 C:US 1:2149 2:174 192.68.122/24 PGE-CNET-C-68-122 C:US 1:2149 2:174 192.68.123/24 PGE-CNET-C-68-123 C:US 1:2149 2:174 192.68.124/24 PGE-CNET-C-68-124 C:US 1:2149 2:174 192.68.125/24 PGE-CNET-C-68-125 C:US 1:2149 2:174 192.80.215/24 PGE-CNET1 C:US 1:2149 2:174 192.80.216/24 PGE-CNET2 C:US 1:2149 2:174 192.80.217/24 PGE-CNET3 C:US 1:2149 2:174 192.80.218/24 PGE-CNET4 C:US 1:2149 2:174 192.80.219/24 PGE-CNET5 C:US 1:2149 2:174 192.80.220/24 PGE-CNET6 C:US 1:2149 2:174 192.80.221/24 PGE-CNET7 C:US 1:2149 2:174 192.80.222/24 PGE-CNET8 C:US 1:2149 2:174 192.80.223/24 PGE-CNET9 C:US 1:2149 2:174 192.80.224/24 PGE-CNET10 C:US 1:2149 2:174 192.80.225/24 PGE-CNET11 C:US 1:2149 2:174 192.80.226/24 PGE-CNET12 C:US 1:2149 2:174 192.80.227/24 PGE-CNET13 C:US 1:2149 2:174 192.80.228/24 PGE-CNET14 C:US 1:2149 2:174 192.80.229/24 PGE-CNET15 C:US 1:2149 2:174 192.80.230/24 PGE-CNET16 C:US 1:2149 2:174 192.80.231/24 PGE-CNET17 C:US 1:2149 2:174 192.80.232/24 PGE-CNET18 C:US 1:2149 2:174 192.80.233/24 PGE-CNET19 C:US 1:2149 2:174 192.80.234/24 PGE-CNET20 C:US 1:2149 2:174 192.80.235/24 PGE-CNET21 C:US 1:2149 2:174 192.80.236/24 PGE-CNET22 C:US 1:2149 2:174 192.80.237/24 PGE-CNET23 C:US 1:2149 2:174 192.80.238/24 PGE-CNET24 C:US 1:2149 2:174 192.80.239/24 PGE-CNET25 C:US 1:2149 2:174 192.80.240/24 PGE-CNET26 C:US 1:2149 2:174 192.80.241/24 PGE-CNET27 C:US 1:2149 2:174 192.80.242/24 PGE-CNET28 C:US 1:2149 2:174 192.80.243/24 PGE-CNET29 C:US 1:2149 2:174 192.80.244/24 PGE-CNET30 C:US 1:2149 2:174 192.80.245/24 PGE-CNET31 C:US 1:2149 2:174 192.80.246/24 PGE-CNET32 C:US 1:2149 2:174 192.80.247/24 PGE-CNET33 C:US 1:2149 2:174 192.80.248/24 PGE-CNET34 C:US 1:2149 2:174 192.80.249/24 PGE-CNET35 C:US 1:2149 2:174 192.80.250/24 PGE-CNET36 C:US 1:2149 2:174 192.80.251/24 PGE-CNET37 C:US 1:2149 2:174 192.80.252/24 PGE-CNET38 C:US 1:2149 2:174 192.80.253/24 PGE-CNET39 C:US 1:2149 2:174 192.80.254/24 PGE-CNET40 C:US 1:2149 2:174 192.102.226/24 EDI C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 192.111.160/19 PAC-BELL-C1 C:US 1:200(128) 2:200(144) 193.184.75/24 SKIRJA-NET2 C:FI 1:701(136) 2:701(134) 3:1800 194.128/16 UK-PIPEX-194-128 C:GB 1:1849 2:701(136) 3:701(134) 4:1800 198.59.109/24 NETBLK-WESTNET C:US 1:1334 198.59.113/24 NETBLK-WESTNET C:US 1:1334 198.59.115/24 DBACYBER C:US 1:1334 198.59.117/24 CINM2 C:US 1:1334 198.59.165/24 NETBLK-WESTNET C:US 1:1334 198.59.177/24 NETBLK-WESTNET C:US 1:1334 198.59.180/24 NETBLK-WESTNET C:US 1:1334 198.63.163/24 NETBLK-SESQUI-CIDR C:US 1:1334 198.81.215/24 WINCOM-DMZ2 C:CA 1:1325 198.139.125/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.139.126/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.139.127/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.139.128/24 NETBLK-CEDAR-CREST-CO C:US 1:97 198.160.139/24 ATSNET C:US 1:3561(218) 2:3561(11) 3:279 4:86 198.175.187/24 BBC-C C:US 1:1800 2:1239 3:1240 198.203.216/24 FDOTMCCO C:US 1:2551(136) 2:1321 199.26.152/24 CAS-C-NET C:US 1:3561(218) 2:3561(11) 3:1225(131) 4:1225(130) 5:1225(129) 199.164.184/24 SKEPSIS C:US 1:1800 2:1239 3:1240 199.208.130/24 SHARPELAN C:US 1:568(144) 199.208.131/24 SDLAN C:US 1:568(144) 199.208.132/24 PSLAN C:US 1:568(144) 199.208.133/24 TDLAN C:US 1:568(144) 199.208.134/24 OCLAN C:US 1:568(144) 199.208.135/24 CCLAN C:US 1:568(144) 199.208.136/24 BARLAN C:US 1:568(144) 199.208.137/24 SATLAN C:US 1:568(144) 199.208.138/24 REDLAN C:US 1:568(144) 199.208.139/24 ISLAN2 C:US 1:568(144) 199.208.140/24 NCTSNPT C:US 1:568(145) 199.211.253/24 NUWCNET1 C:US 1:568(145) 202.68.0/19 APNIC-CIDR-BLK C:HK 1:1321 204.4.113/24 PSINET-C4 C:US 1:2149 2:174 204.6.57/24 PSINET-C4 C:US 1:2149 2:174 204.6.58/24 PSINET-C4 C:US 1:2149 2:174 204.6.59/24 PSINET-C4 C:US 1:2149 2:174 204.6.83/24 PSINET-C4 C:US 1:2149 2:174 204.69.162/24 OMNINOC-NET C:US 1:3561(218) 2:3561(11) 3:114 204.73.217/24 OJIBWE C:US 1:1225(130) 2:1225(129) 3:1225(131) 4:1239 5:1240 6:1800 204.74.68/24 NET-WCLASS C:US 1:1957 204.75.175/24 SECMEG C:US 1:2149 2:174 204.87.64/24 OKLAOSF-1 C:US 1:93 204.89.187/24 NOSPARROW C:US 1:3561(11) 2:3561(218) 3:1240 4:1239 5:1800 204.120.204/24 NET-APCI C:US 1:1239 2:1800 3:1240 204.128.180/24 GIGOTECH C:US 1:1800 2:1239 3:1240 204.134.0/24 INNSOL C:US 1:1334 204.134.1/24 NETBLK-CSN-BLOCK-6 C:US 1:1334 204.134.2/24 DWF-DOM C:US 1:1334 204.134.3/24 DECCS C:US 1:1334 204.134.4/24 WACKO-NET C:US 1:1334 204.142.79/24 NETBLK-DES2 C:US 1:97 204.142.80/24 NETBLK-DES3 C:US 1:97 204.142.83/24 NETBLK-FCDS-C-142-83 C:US 1:97 204.142.84/24 NETBLK-FCDS-C-142-84 C:US 1:97 204.142.87/24 NETBLK-DALCOMP1 C:US 1:97 204.142.88/24 NETBLK-DALCOMP2 C:US 1:97 204.142.89/24 OPTUS-C-142-89 C:US 1:97 204.142.90/24 OPTUS-C-142-90 C:US 1:97 204.142.91/24 NSLABS2 C:US 1:97 204.142.92/24 NSLABS3 C:US 1:97 204.142.93/24 NETBLK-RIDER4 C:US 1:97 204.142.94/24 NETBLK-RIDER5 C:US 1:97 204.142.95/24 NETBLK-RIDER6 C:US 1:97 204.142.96/24 NETBLK-RIDER7 C:US 1:97 204.142.97/24 NETBLK-RIDER8 C:US 1:97 204.142.98/24 NETBLK-RIDER9 C:US 1:97 204.142.99/24 NETBLK-RIDER10 C:US 1:97 204.142.100/24 NETBLK-RIDER11 C:US 1:97 204.142.111/24 CFRNJ2 C:US 1:97 204.142.112/24 CFRNJ3 C:US 1:97 204.145.166/24 NET-DASHOPS C:US 1:1239 2:1800 3:1240 204.147.224/20 SCRUZ-NET-C2 C:US 1:3561(11) 2:3561(218) 3:1240 4:1239 5:1800 204.153.160/22 CORPCOMM C:US 1:3561(11) 2:3561(218) 3:685 4:73 5:101 204.164.64/24 SML-64 C:US 1:560 2:701(136) 3:701(134) 204.168.92/22 NET-HOUGHTON C:US 1:1239 2:1800 3:1240 204.213.70/23 NET-NEXUS C:US 1:1239 2:1800 3:1240 204.222.24/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) 204.222.25/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) 204.222.26/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) 204.222.27/24 NETBLK-WEBSTER-FLD-C- C:US 1:568(145) Deletions: --131.127/16 ASGARRETT C:US 1:1239 2:1800 3:1240 4:1225(130) 5:1225(129) 6:1225(131) --204.168.112/22 NET-GREATNECK.LIB.NY C:US 1:1239 2:1800 3:1240 Expanded listing, sorted by country, then by organization: ========================================================== The "Expanded Listings" section of this NWG report has been retired since it is sorted by countries and network organization addresses. The replacement configuration generation system is based on the Internet Routing Registry (briefly called the "Global Routing Registry"). See the file ftp.ra.net:pub/radb/OVERVIEW for more information. The remainder of this report will also be retired shortly. AS690 CIDR Squeezings Report: 9795 Nets, 169 ASs, 2643 Aggregates ------------------------------------------------------------------ 9795 (85%) of the ever-announced more-specific routes within aggregates have been withdrawn. 241 of those were withdrawn within the last week. 318 the week before that. 180 the week before that. 169 ASs have registered aggregates in the PRDB. 147 of those are announcing aggregates. 80 have withdrawn at least one more specific route. 2643 Aggregates are configured. 1906 of these were Top-Level Aggregates (not nested in another aggregate). 1454 of these are being announced to AS690. 1026 of those have at least one subnet configured (the other 428 may be saving the Internet future subnet announcements). 855 have stopped announcing at least one configured more specific route. 832 have stopped announcing half of their configured more specific routes. 777 have stopped announcing most (80%) of their more specific routes. See merit.edu:pub/nsfnet/cidr/cidr_savings for more detail. ----------------------------------------------------------- ========================================================== The configuration reports which reflect today's update will be available for anonymous ftp on nic.merit.edu by 08:00 EST : configuration reports -- nic.merit.edu:nsfnet/announced.networks: as-as.now as-gw.now ans_core.now country.now net-comp.now nets.doc nets.non-classful nets.tag.now nets.unl.now NSS routing software configuration files -- nic.merit.edu:nsfnet/backbone.configuration: gated.nss<NSS number>.t3p Information is also avaiable through the PRDB whois server. Type "whois -h prdb.merit.edu help" for details. -------------------------------------------------------------------------- PRDB CHANGES: (Updated January 19, 1994) As of 1/19/95, ACKs and NAKs will no loger be required (or even read) in the processing of NACRs. In early 1995, as part of the transition to the new Internet Routing Registry (IRR), the Policy Routing Database (PRDB) will be retired. Many of the functions of the PRDB (including generation of router configurations for NSFNET) will be produced based on data from the Global Routing Registry. This change to the NSFNET Backbone service will involve the following changes: - The method for submitting new nets to be routed over AS690 will change. Instead of submitting a NACR to nsfnet-admin(a)merit.edu, you will need to submit a "route template" to auto-dbm(a)ra.net . - Additions and entries to the new registry will be made by the Home AS which creates the route for each net, rather than being submitted by a AS690 peer AS. - Most of the PRDB reports (listed above) will no longer be produced. Equivalent information for most of these reports is available from the global Routing Registry. These are major changes to the system. These changes are being made in order to migrate NSFNET customers and the global user community to a global Internet Routing Registry system, which will be more capable of supporting user needs after the termination of the NSFNET Backbone services in April 1995. For more information, set your web browser to http://www.ra.net/rrinfo.html , or use anonymous ftp to obtain the files "OVERVIEW" and from the directory "ftp.ra.net:pub/radb". Merit would like to minimize the number of problems that this transition may cause you. In order to help us help you through the transition, please send your concerns, your needs, and suggestions on how we can make this happen smoothly to merit-ie(a)merit.edu. The archived discussion list "db-disc(a)merit.edu" also exists for discussion of PRDB and RADB issues. Send a message to "db-disc-request(a)merit.edu" to subscribe. --Dale Johnson (dsj(a)merit.edu) -------------------------------------------------------------------------- Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nic.merit.edu machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfnet/announced.networks" and get the files template.net, template.net.README, template.gate, and template.as. *** Note: As of March 1, 1994, NSFNET AUP NACRs must use the template.net *** (NACR) version 7.1, or the NACR will be returned unprocessed. ******************************* --Steven J. Richardson Merit/NSFNET sjr(a)merit.edu

1 0

** Transition updates
by Steven J. Richardson 23 Jan '95

23 Jan '95

Please submit your transition updates ASAP, e.g., not the day before. Thank you, Steve Richardson/Merit

1 0

CERT Advisory CA-95:01.IP.spoofing.attacks.and.hijacked.terminal.connections
by cert-advisory＠cert.org 23 Jan '95

23 Jan '95

============================================================================= CA-95:01 CERT Advisory January 23, 1995 IP Spoofing Attacks and Hijacked Terminal Connections ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of attacks in which intruders create packets with spoofed source IP addresses. These attacks exploit applications that use authentication based on IP addresses. This exploitation leads to user and possibly root access on the targeted system. Note that this attack does not involve source routing. Recommended solutions are described in Section III below. In the current attack pattern, intruders may dynamically modify the kernel of a Sun 4.1.X system once root access is attained. In this attack, which is separate from the IP spoofing attack, intruders use a tool to take control of any open terminal or login session from users on the system. Note that although the tool is currently being used primarily on SunOS 4.1.x systems, the system features that make this attack possible are not unique to SunOS. As we receive additional information relating to this advisory, we will place it, along with any clarifications, in a CA-95:01.README file. CERT advisories and their associated README files are available by anonymous FTP from info.cert.org. We encourage you to check the README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description This description summarizes both the IP spoofing technique that can lead to root access on a system and the tool that intruders are using to take over open terminal and login connections after they get root access. We are currently seeing attacks in which intruders combine IP spoofing with use of the tool. However, these are two separate actions. Intruders can use IP spoofing to gain root access for any purpose; similarly, they can highjack terminal connections regardless of their method of gaining root access. IP spoofing To gain access, intruders create packets with spoofed source IP addresses. This exploits applications that use authentication based on IP addresses and leads to unauthorized user and possibly root access on the targeted system. It is possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. It is important to note that the described attack is possible even if no reply packets can reach the attacker. Examples of configurations that are potentially vulnerable include - routers to external networks that support multiple internal interfaces - routers with two interfaces that support subnetting on the internal network - proxy firewalls where the proxy applications use the source IP address for authentication The IP spoofing attacks we are currently seeing are similar to those described in two papers: 1) "Security Problems in the TCP/IP Protocol Suite" by Steve Bellovin, published in _Computer Communication Review_ vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD Unix TCP/IP Software" by Robert T. Morris. Both papers are available by anonymous FTP from ftp.research.att.com:/dist/internet_security Bellovin paper: ipext.ps.Z Morris paper: 117.ps.Z Services that are vulnerable to the IP spoofing attack include SunRPC & NFS BSD UNIX "r" commands anything wrapped by the tcp daemon wrappers - site dependent; check your configuration X windows other applications that use source IP addresses for authentication Hijacking tool Once the intruders have root access on a system, they can use a tool to dynamically modify the UNIX kernel. This modification allows them to hijack existing terminal and login connections from any user on the system. In taking over the existing connections, intruders can bypass one-time passwords and other strong authentication schemes by tapping the connection after the authentication is complete. For example, a legitimate user connects to a remote site through a login or terminal session; the intruder hijacks the connection after the user has completed the authentication to the remote location; the remote site is now compromised. (See Section I for examples of vulnerable configurations.) Currently, the tool is used primarily on SunOS 4.1.x systems. However, the system features that make this attack possible are not unique to SunOS. II. Impact Current intruder activity in spoofing source IP addresses can lead to unauthorized remote root access to systems behind a filtering-router firewall. After gaining root access and taking over existing terminal and login connections, intruders can gain access to remote hosts. III. Solutions A. Detection IP spoofing If you monitor packets using network-monitoring software such as netlog, look for a packet on your external interface that has both its source and destination IP addresses in your local domain. If you find one, you are currently under attack. Netlog is available by anonymous FTP from net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz MD5 checksum: 1dd62e7e96192456e8c75047c38e994b Another way to detect IP spoofing is to compare the process accounting logs between systems on your internal network. If the IP spoofing attack has succeeded on one of your systems, you may get a log entry on the victim machine showing a remote access; on the apparent source machine, there will be no corresponding entry for initiating that remote access. Hijacking tool When the intruder attaches to an existing terminal or login connection, users may detect unusual activity, such as commands appearing on their terminal that they did not type or a blank window that will no longer respond to their commands. Encourage your users to inform you of any such activity. In addition, pay particular attention to connections that have been idle for a long time. Once the attack is completed, it is difficult to detect. However, the intruders may leave remnants of their tools. For example, you may find a kernel streams module designed to tap into existing TCP connections. B. Prevention IP spoofing The best method of preventing the IP spoofing problem is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network in order to prevent a source IP spoofing attack originating from your site. The following vendors have reported support for this feature: Bay Networks/Wellfleet routers, version 5 and later Cabletron - LAN Secure Cisco - RIS software all releases of version 9.21 and later Livingston - all versions If you need more information about your router or about firewalls, please contact your vendor directly. If your vendor's router does not support filtering on the inbound side of the interface or if there will be a delay in incorporating the feature into your system, you may filter the spoofed IP packets by using a second router between your external interface and your outside connection. Configure this router to block, on the outgoing interface connected to your original router, all packets that have a source address in your internal network. For this purpose, you can use a filtering router or a UNIX system with two interfaces that supports packet filtering. NOTE: Disabling source routing at the router does not protect you from this attack, but it is still good security practice to do so. Hijacking tool There is no specific way to prevent use of the tool other than preventing intruders from gaining root access in the first place. If you have experienced a root compromise, see Section C for general instructions on how to recover. C. Recovery from a UNIX root compromise 1. Disconnect from the network or operate the system in single-user mode during the recovery. This will keep users and intruders from accessing the system. 2. Verify system binaries and configuration files against the vendor's media (do not rely on timestamp information to provide an indication of modification). Do not trust any verification tool such as cmp(1) located on the compromised system as it, too, may have been modified by the intruder. In addition, do not trust the results of the standard UNIX sum(1) program as we have seen intruders modify system files in such a way that the checksums remain the same. Replace any modified files from the vendor's media, not from backups. -- or -- Reload your system from the vendor's media. 3. Search the system for new or modified setuid root files. find / -user root -perm -4000 -print If you are using NFS or AFS file systems, use ncheck to search the local file systems. ncheck -s /dev/sd0a 4. Change the password on all accounts. 5. Don't trust your backups for reloading any file used by root. You do not want to re-introduce files altered by an intruder. --------------------------------------------------------------------------- The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic, Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our understanding of these problems and their solutions. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet E-mail: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA Past advisories, CERT bulletins, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT is a service mark of Carnegie Mellon University.

1 0

Re: Listing of Peering NSPs at every NAP?
by Pushpendra Mohta 23 Jan '95

23 Jan '95

Pushpendra Mohta writes: > > Carlos M. Gutierrez writes: > > > > Hello gentlemen/-ladies, > > > > I was wondering if anybody knows of a listing of National Service > > Providers that peer at each NAP? Something somewhat like the following: > > > > SPRINT-NAP: SprintLink > > UUNET > > NearNet > > Net99 > > SURANet > > etc. > > > > PAC-BELL-NAP: ANS CO-RE/AOL > > Netcom > > etc., etc. > > > > Any place this info exists FTP-friendly? > > > > I suppose I could spend a couple of hours doing traceroutes; I would love > > to...honest...but for the moment I am limited to CompuZerve access... > > > > TIA, > > > > Carlos M. Gutierrez 74453.3064(a)compuserve.com > > San Juan, Puerto Rico > > > > p.s. If possible, also e-mail replies to me directly, as I never received > > confirmation of my subscription to this list. > > > > > > I am having someone drawup a map served by mosaic based on information > provided by Sean Doran of Sprint. > > It will be available over the weekend at > > http://www.cerf.net/cerfnet/interconnects.html > > Some information is available at http://www.ra.net/transition.html > > --pushpendra > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > Director, CERFnet +1 800 876 2373 > > Ok, the first cut of this map is up, no doubt with some errors. Please let meg(a)cerf.net know of errors. --pushpendra Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 Director, CERFnet +1 800 876 2373

2 1

Amended NETSTAT Minutes for 7 Dec. 1995
by Gene Hastings 23 Jan '95

23 Jan '95

[This incorporates the corrections sent to NANOG. Slides will be available online shortly for BBN, InternetMCI, Sprint NAP and Sprintlink.] Network Status Reports met on 7 December, 1994 from 0930 to 1145. Scheduled presentations were ANS (Rob Lehman), NSFNET Transition (Elise Gerich), InternetMCI (Phill Gross), BBN (John Curran), Sprint NAP (Tim Clifford) and SprintLink (Sean Doran) In addition to the presentations and Q&A, several meta-issues were raised or implied (furished along with my attempt to digest the pulse of the group). Is it appropriate to give what is essentially a marketing presentation at IETF? The consensus seems to be "no" if it is solely and blatantly such, but there is dissention as to where the line is. With the increasing activity of for profit concerns in the Internet, will it be possible to continue the openness of past years' presentations wrt traffic, performance, uptime statistics, etc.? [Despite the fears or predictions of some, there appears to come continuing openness, AND examples of extremely closed practices. I think that collegial backpressure has ceased to be sufficient to maintain the historical levels of disclosure and cooperation. - efh] In the light of these questions, what is the charter of this group? (including what is desirable vs. what is acceptable). [I think this is an ongoing process. Does commercial necessarily mean concealed? I think in the context of an interconnected, interdependent environment, it can't in the long run. - efh] Beyond concerns about openness, there are areas of concern not being addressed at all: What is the forum for operations, engineering and troubleshooting above TCP/UDP? Traditional IP regionals and carriers have been content to (determined to?) focus their energies on transport and routing. What is the forum for general end-to-end problem solving? Presentations: ANS Rob Lehman,<rll(a)ans.net> [See slides - only supplemental notes follow] ANSNET traffic surpassed 100m inbound packets in Nov.! CIDR note: after AUP disappears, there ought to be further aggregation possible ANS' NAP connectivity status: Connection to the Sprint NAP was installed on 9-21-94. At this time (7 Dec. 94) it's only been operational since 2 weeks, but substantial traffic has been exchanged Connection to the PacBell NAP was installed on 10-14-94, but is not in production. Connection to the Ameritech NAP was installed on 11-22-94, but is not in production. A MAE+ FDDI Installation plan has been established. Its exact schedule is contingent on logistics. Real Soon Now. ANS did link optimizations for cross-country trunking, to address an imbalance in the relative utilizations of their northern and southern routes. After testing, they are further considering deployment of Random Early Drop. Transition Elise Gerich <epg(a)merit.edu> [No slides - see contemporaneous presentations to IESG, etc.] NONE of the ENSSen have been retired. The regionals' transition to non-NSF Inter-Regional Connectivity has been slow. Target dates of Nov. 1 and Dec. 1 have been missed, Merit is hoping for ~ Jan. 1 terminations + 60 days... THEnet and MOREnet have made the transition to SprintLink. SURAnet has moved traffic to MCInet, but has not formally notified Merit of the ability to terminate the ENSS connection. (THEnet was previously sharing Inter-Regional Connectivity with Sesquinet ) CA*NET is close to transition to MCI Interconnection point status: The Sprint NAP has connections from Sprint, MCI, and NSFNET. In DC, at MFS facilities, everyone is on MAE and is committed to connecting to MAE+. At the Ameritech NAP, MCI and NSFNET are about to start peering, with Sprint to connect soon. PacBell has MCI and ANS are peering, and Sprint will connect soon. Route servers are present at MAE, the PacBell NAP, the Ameritech and the Sprint NAP. Routing DB deployment and transition. The applications are moving from PRDB (@merit) to RA (db-admin(a)radb.ra.net) At some point, Merit will do dual use of NACR and RADB forms, followed by retirement of NACR (transition ca. Jan. 15.) Merit has recommended to NSF that during transition (Jan.-Jun., there should be no need to specify AUP. If anyone is still relying on PRDB reports they should contact Dale!!! InternetMCI Phill Gross <0006423401(a)mcimail.com> [see pretty slides. In color. Phill apologized.] Problems were experienced transitioning SURAnet, thus delaying the CoREN schedule. "DS3 networking is not yet a commodity service." - experienced some problems in the routers. Questions from the floor: What management platform does InternetMCI use? Phill: Hewlett- Packard OpenView, plus homegrown tools and extensions. What Other nets beside CoREN is MCI serving? Phill: CA*NET is partially transitioned...(at 3Mb), WIDE (at T1) and BTnet (at E1) InternetMCI NAP connectivity status: Chicago (Ameritech) was connected a the end of last week, MCI is connected and peering at Sprint, MAE and CIX. ANS and MCI are interconnected at FDDI at Hayward CA. common PoP (Phill: Thanks for the cooperation, ANS!) Q: When will MCI be connected to FIX-W? Phill: I don't know. It's underway, maybe by the end of year, approximately the same as CIX- SMDS, MAE+. Q: What's the status of the vBNS? Phill: we're deploying a testnet, and full rollout 1Q95 at OC-3. The testnet should be operational before Christmas. BBN John Curran <curran(a)bbn.com> [Admittedly marketing slides.] BBN is upgrading the NEARNET spine in the Boston area, migrating from microwave Ethernet to fiber (MFS 10Mb over NYNEX T3). Currently BBN has almost 2000 SNMP managed items... Operations/NOC/NIC tip: you can head off phone calls by giving seminars! BBN is now offering "Turnkey Internet Server" (Pentium/BSDi) Internet Site Patrol - managed firewall (BBN CONTROLS it), with remote management done by BBN ISC over a secure channel. It's derived from TIS products, and supports telnet, ftp, smtp, nntp, www, x BBN strenuously wants to know how to pursue end-to-end problem solving (they still subscribe to 'the router is BBN's, we control the horizontal, we control the vertical). Sprint NAP, Tim Clifford <tcliff(a)sprint.net>(New PI) Report on the Sprint "NY" NAP (in Southern NJ). It is now (Dec. 94) a dual FDDI ring, and in Jan. will be converted to a DEC Gigaswitch. [See before and after diagrams]. Connected, parties include MCI, NSFNET, Sprint and Cerfnet. A Route Server is present and running. Aside: Sprint has "always thought about ATM" [the implication being that they felt is wasn't ready - efh] Question: the DEC GigaSwitch has DS3 cards. Have you considered access this way? Tim: not really. [It's my understanding that a GS ATM interface can only talk to other GS. - efh] Q: being already co-located, can folks try alternate interconnect technologies? Tim: likely. Try us. SprintLink, Sean Doran <smd(a)sprint.net> Sprintlink's T1 backbone was melting down, and was supplanted by a parallel T1 net. The parallel T1 links are being converted to DS-3s in the next few weeks.[see diagram]. T3 customers feed directly into BB routers to avoid saturating local FDDI rings For trans-US international connectivity, ICM has 2 T3 between Stockton, CA and DC. The design goal in separation of SprintLink and ICM was the assurance of symmetry of routing. [Context?] preservation of next hop in routing is critical feature (could not wait for IDRP) Q: What about fears of an ASpath explosion in routing tables? Sean: Too late. Already here! Although a wise man might urge that one suffer fools gladly, this should not be construed as license for any fool to demand that one do so. -Frederick William Kantor

1 0