July 1995 - Test - lists.nanog.org

Continued IP Spoofing Attacks (INFO#95.16723)
by CERT Coordination Center 21 Jul '95

21 Jul '95

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================== CONTINUED IP SPOOFING ATTACKS CERT Coordination Center July 21, 1995 ============================================================================== **** This note is the same ``heads-up'' that was originally sent on June 29, **** 1995. It is being resent because some recipients were unable to read **** it. Because of the importance of the subject matter, we are resending **** with a PGP signature but without a MIME header. Over the past few weeks, we have received reports of 170 IP spoofing attacks against Internet sites internationally. We are sending you this "heads-up" because you, a network service provider, are a likely target. At least 80 of the targets we know of are name servers, routers, and other network operation systems. The attacks have been largely successful, we continue to receive reports, and we are concerned that more attacks are going undetected. We urge you to check your systems and routers for any signs of compromise and to use the information in CERT advisory CA-95:01, "IP Spoofing Attacks and Hijacked Terminal Connections," to help protect yourself, detect IP spoofing attacks, and recover from root compromises. The advisory is available by anonymous FTP from ftp://info.cert.org/pub/cert_advisories This "heads-up" contains additional information about what you can do, as well as issues to consider before taking action. Please feel free to forward this to other providers of Internet services. What is 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. Examples are the rsh and rlogin services. 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 Communicating with us - ---------------------- Warning: For sensitive information, use encrypted email. You will find the CERT public PGP key at the end of this document. We would appreciate it if you would let us know whether you are watching for IP spoofed packets on your networks (or plan to do so). If you see spoofed packets, we'd like to learn how many you see and from how many different sites; this will help us determine the scope and pattern of the attacks. We will keep all detailed information and the identity of organizations confidential. Because of our workload, we must ask you not to send log files of activity, but we would be happy to work with you as needed on how to interpret data that you may collect. If you see activity that indicates an attack is in progress, we encourage you to contact your customer, or other involved sites or their service provider. We have some general information on IP spoofing and on recovering from a compromise that we can make available to you for your customers' use. We would also be happy to provide guidance and advice, if needed, on how to handle incidents and work with law enforcement. ............................................................................. Some things you can do - ---------------------- It is possible to check network traffic for indications of the type of attack we are currently seeing. Before doing so, please look at the next section, "Issues to consider before taking action." There are several classes of packets that you could watch for. The most basic is any TCP packet where the network portion (Class A, B, or C or a prefix and length as specified by CIDR, the Classless Inter-Domain Routing specification) of the source and destination addresses are the same but neither are from your local network. These packets would not normally go outside the source network unless there is a routing problem, worthy of additional investigation, or the packets actually originated outside your network. The latter may occur with Mobile IP testing, but an attacker spoofing the source address is a more likely cause. For a NAP or NSP, the interface into which a packet arrived indicates the direction of the source of the attack. The packet's destination address indicates the "trusted" host involved in an attack. That information suggests which hosts may be under attack. There are public domain and vendor provided tools available for checking your networks for IP spoofed packets. Among them are Argus, tcpdump, and snoop. Argus 1.5 - --------- Argus is an IP network transaction-auditing tool developed at the Software Engineering Institute of Carnegie Mellon University. The Argus 1.5 distribution includes scripts that perform simple network administrative tasks, one of which is IP spoofing detection. The data that Argus generates makes it possible to analyze network activity and performance in ways that have not been possible before. For example, you can answer questions such as, "Were there any IP spoofing attempts into our firewall network over the past 8 hours?" The developers of Argus have made the tools available from ftp://ftp.sei.cmu.edu/pub/argus-1.5 If you have any questions, comments, or suggestions, please send mail to argus(a)sei.cmu.edu. Scripts - ------- At the end of this document ("Attachment A") are scripts you may want to use to check your network. We are aware that the Internet is now "classless," meaning that the old notion of class A, B, and C addresses is being replaced with a prefix and length notation, also known as CIDR. Even so, the scripts, which are based on classes, may be useful to some service providers. In all the IP spoofing incidents reported to us to date, we believe that the scripts would have shown the spoofed packets. (The problem here is that these scripts may either show other packets labeled as spoofed or not show true spoofed packets due to CIDR.) A standalone machine running tcpdump or equivalent should be able to run these scripts without affecting the performance of the local net. It may be possible to configure routers to do this check directly but we are not currently aware of any systems on which this is possible. .............................................................................. Issues to consider before taking action - --------------------------------------- Before writing this "heads-up," we consulted colleagues on other response teams, several network service providers, and other technical experts. They raised the following issues, and there surely are others you should consider before taking action. Technical and performance issues: - There may be too many "false positives." Two causes are mobile IP and misconfigurations; there may be other causes as well. - The feasibility of installing network monitors may depend on network topology. - It is not clear how many monitoring machines you would need to pinpoint the problem. - When the tcpdump and snoop scripts were tested on a dedicated Sun IPX connected to a T1, the impact on performance was only marginal. Long-haul tests with similar scripts do not have performance problems either. - Anything above a T1 is going to cause some performance problems (applications like tcpdump and snoop do not work very well at all on DS3 or FDDI interfaces). Legal issues: - - Some service providers believe that checking your network as we suggest is all right; others believe that there may be a problem. We urge you to check with your legal advisors about analyzing packet header information, analyzing traffic content to detect unauthorized activity, and analyzing internal traffic and customer-bound traffic. - - For US service providers, the Digital Telephony Bill of 1994 is relevant; in particular, check the amended provision found at 18 U.S.C. 2511(2) (a) (i), which permits an electronic communications service and its employees to ...intercept, disclose, or use that communication in the normal course of...employment while engaged in any activity which is a necessary incident to the rendition of...service or to the protection of the rights or property of the provider of that service.... .............................................................................. Attachment - Scripts for Checking Networks - -------------------------------------------- We have tested the following scripts on a recent version of tcpdump and snoop (192.9.200.0 would be replaced by the site's local net, of course): --- script for tcpdump --- #!/bin/sh tcpdump 'tcp and not dst net 192.9.200.0 and ( (ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]) )' (Note this only seems to work with tcpdump-3.0.2 and libpcap-0.0.6 currently.) --- script for snoop --- #!/bin/sh snoop 'tcp and not net 192.9.200.0 and ((ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]))' (Note that this does not appear to work with Solaris 2.3 machines.) To more accurately analyze network traffic, it is useful to first describe the network topology; for example: ---------------- | INTERNET | ---------------- | ---------- | | NETWORK | ---------------- | MONITOR | | ROUTER | ---------- ---------------- | | | | ----------------------------------------------------------------- |MAC-A |MAC-B |MAC-C --------- --------- --------- |ROUTER | |ROUTER | |ROUTER | --------- --------- --------- | | | | | | | | | | | | | | | | | | | | | | | | | | | Ca Cb Cc Cd Ce Cf Cg Ch Ci (MAC-A, MAC-B, and MAC-C refer to the ethernet addresses of the router interfaces attached to the same network as the network monitor machine.) In this case, the machine used to check network traffic could be any machine capable of running tcpdump, snoop, or any other packet capture and analysis software. This machine could be programmed so that any packets that match the following expression are displayed. tcp and ( not ether src MAC-A and ( src net Ca or src net Cb or src net Cc ) not ether src MAC-B and ( src net Cd or src net Ce or src net Cf ) not ether src MAC-C and ( src net Cg or src net Ch or src net Ci ) ) This expression looks at the source address of each packet and identifies those that did not originate from the correct interface. This example should be extensible to take CIDR into account. For example, if the CIDR specification of network Ca is 192.9.200/21, then the sub-expression: src net Ca should be replaced with: ip[12:4]&0xfffff800=192.9.200.0 .............................................................................. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMA/8F3VP+x0t4w7BAQGKfgQArR6jBz+HjRbPBRAjO88aNIaH/ZbBzt1K cPDE54nLWa0+CP4F4ZWhn+UH1SMdRrLFdYZdD1sn5j56zx+nXmzo2sL3eRvylpdp LigpavVWJoOoC8XY8AJqUCT+A4txd4QacawGZMMbedIi9IyzU/33ia7BIb4wW/k6 bidvD0ExGNQ= =nyX9 -----END PGP SIGNATURE-----

1 0

Internic procedure problems
by Michael Dillon 21 Jul '95

21 Jul '95

I've been thinking about this incident with the wrong address in the .net domain for ns2.bc.net and I have come to the conclusion that the Internic needs to review some of their procedures. First of all, I wonder why they don't run a sanity check on the top level zone files from time to time to make sure that the correct domain names and IP addresses are recorded. If this were done and a sanity check was also done at the time of any changes to the zone files, then this kind of problem would not occur. THis is not the first time I have encountered such a problem. A few weeks ago I helped a small college in California sort out a problem with their email which was the result of the incorrect nameserver being recorded in the .ca.us domain. Another thing that would be nice to see is some method for updating domain information similar to the way routing policy is updated. If I wish to change secondary nameservers, I should be able to directly update records for my domain rather than submit an email request and wait 3-4 weeks for an overworked human being to get around to it. This is especially irritating for us because when we switched providers and therefore needed to switch secondary nameservice, it only took a few days to get the in-addr domains changed but our .net domain is dragging on forever. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com

3 2

New and improved Traceroute
by Ehud Gavron 21 Jul '95

21 Jul '95

Steffen Baur identified a long-standing bug in traceroute that causes it to appear to hang on non-returned packets on hosts which received lots of ICMP traffic. This fix, as well as some ANSI stuff to make it work on SunOS, Ultrix, BSDI, (and of course, VMS), have now been integrated. ftp.aces.com, cd [.software.traceroute], mget *.*, there's a 0_readme.txt and traceroute.c. This pretty much completes any of the major fixes I'd planned to do for this quarter, so unless someone comes up with anything revolutionary to put in, I won't post another comment for a while... Ehud gavron(a)aces.com

1 0

RIPE automatic inaddr-arpa checking tool available
by RIPE NCC IN-ADDR. ARPA Role Account 21 Jul '95

21 Jul '95

Dear all, After many requests I have published the inaddr-arpa checking tool I developed at the RIPE NCC. We use it now at RIPE NCC quite for some time and it really saves us a lot of time, although the program is not perfect and still needs some polishing. Beware of changing/adapting the tool too much since I expect to make some big changes in the output format to facilitate further automatic processing. Furthermore, I want to split it in some smaller files and a config file for better maintainability. Of course comments and bug reports are welcome. Please read the included README file for more details. Kind regards, David Kessens RIPE NCC PS I am on vacation during the next two weeks, but I will certainly deal with any comments/bug reports when I return! -------- README for the inaddrtool v0.1 Date: 950719 Author: David Kessens, RIPE NCC NOTE: THE TOOL HAS BEEN MADE PUBLICLY AVAILABLE BECAUSE OF THE LARGE NUMBER OF REQUESTS OF OUR CUSTOMERS TO DO SO. THE TOOL ITSELF HAS PROVEN IT'S USEFULNESS, BUT NOTE THE FACT THAT I EXPECT TO MAKE SOME BIG CHANGES BEFORE RELEASING A FINAL VERSION. ALSO SOME ADD-ON PROGRAMS THAT WILL MAKE IT POSSIBLE TO ADD THE REVERSE DELEGATION CHANGES/REQUESTS AUTOMATICALLY TO (Y)OUR ZONEFILES ARE STILL MISSING. THE PROGRAM IS DESIGNED AS SITE INDEPENT AS POSSIBLE. PLEASE USE THE NORMAL PROCEDURE AS DESCRIBED IN RIPE-105 IF YOU WANT TO DO A REVERSE DELEGATION REQUEST FOR A REVERSE DOMAIN MANAGED BY THE RIPE NCC, BUT SEND YOUR REQUEST TO <AUTO-INADDR(a)RIPE.NET> INSTEAD OF <HOSTMASTER(a)RIPE.NET> Reverse delegation tool (Alpha version!) ---------------------------------------- As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. The reverse delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. The most recent version of the tool is now publicly available at: ftp://ftp.ripe.net/tools/inaddrtool0.1.tar.gz The tool uses some other external programs for gathering the information it needs for checking your zone files: ftp://ftp.ripe.net/tools/ping.tar.Z ftp://ftp.ripe.net/tools/dns/host.tar.Z ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta3.shar.gz Installing the software: - uncompress/unzip and untar the tool and the external programs - edit the variables in the source code (if needed): $TESTMODE=1 for testing, 0 for normal use $UPDLOGDIR="Directory for logging the incoming requests"; $ACKLOGDIR="Directory for logging the outgoing acknowledgements"; $FWLOGDIR="Directory for logging the outgoing approved requests"; $MSGQUEUEDIR="Directory for temporarily storing the requests"; $NSNAME="The name of your nameserver"; $NAMESERVERCHECK=; see for details the source code $MAILCMD=; see for details the source code $NICECMD="Your nice program if you want" else use ""; $HUMANMAIL="The E-mail address of the human processing the approved requests and answering questions. When $TESTMODE=1, all mail will be send to this address"; $AUTOMAIL="The E-mail address of the mail box that will auto process incoming requests"; - Put something like: "|/home/user/bin/inaddrtool 2>/dev/null" in the .forward file of user $AUTOMAIL Note: there is *NO* queuing mechanism yet, so beware of overloading your machine with a large number of requests. The input: The tool expects to read an E-mail message from standard input although there is no problem when using it stand-alone. The E-mail message should contain a valid RIPE database object as described in the ripe-105 (ftp://ftp.ripe.net/ripe/docs/ripe-105) procedure. When the automated procedure does not detect any errors, the request is forwarded to the $HUMANMAIL role account person for some additional manual checks and the processing of the delegation itself. An acknowledgement of this fact is also sent to the people mentioned in the From:/Reply-To: and Cc: field in the E-mail message. The tool will return an error report if errors are found. If $TESTMODE=1 all mail will be send to $HUMANMAIL. You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible TEST - do the checks, but sent only a report back to the user even if no errors are found You also might want to use the special variable NSNAME that's documented in the source code itself (for experts only). RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>.

1 0

Re: Internic procedure problems
by Geoff Huston 21 Jul '95

21 Jul '95

That last null message from me was fat finger syndrome - sorry 'bout that. I was just noting that there is a WEB page which deals in in-addr delegations at http://aunic.net/aunic/inaddr-template.html The procedure does not email the SOA with the delegation details unless the listed nameservers are a) visible b) functioning and c) consistent. It would be trivial to modify this form to handle generic domain names rather than the special case of in-addr.arpa domain names. Geoff >From list-admin(a)merit.edu Fri Jul 21 08:32:34 1995 >From: Geoff Huston <G.Huston(a)aarnet.edu.au> >Subject: Re: Internic procedure problems >To: markk(a)internic.net (Mark Kosters) >Date: Fri, 21 Jul 1995 07:31:46 +1000 (EST) >Cc: kozowski(a)structured.net, nanog(a)merit.edu > >> >> Its coming - now that the new domain templates are getting to be a larger >> and larger percentage of the total daily domain intake. >> >> Mark >> > >> > >Another thing that would be nice to see is some method for updating domain >> > >information similar to the way routing policy is updated. If I wish to >> > >change secondary nameservers, I should be able to directly update records >> > >for my domain rather than submit an email request and wait 3-4 weeks for >> > >an overworked human being to get around to it. >> > >> > Somthing along the lines of the auto-dbm for the RADB would be great for >> > domain name chages, etc. Just my $.02. >> >> -- >> >> Mark Kosters markk(a)internic.net +1 703 742 4795 >> Software Engineer InterNIC Registration Services >> >> > > >

2 1

Re: Internic procedure problems
by Eric Kozowski 20 Jul '95

20 Jul '95

>Another thing that would be nice to see is some method for updating domain >information similar to the way routing policy is updated. If I wish to >change secondary nameservers, I should be able to directly update records >for my domain rather than submit an email request and wait 3-4 weeks for >an overworked human being to get around to it. Somthing along the lines of the auto-dbm for the RADB would be great for domain name chages, etc. Just my $.02. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS3

4 3

Mae-East instability
by Curtis Villamizar 20 Jul '95

20 Jul '95

Some of our peers have been dropping BGP a bit more often lately. Somebody had a real bad day on Tuesday. Jul.18: 192.41.177.252 1:35:13 mae-east-rt2.es.net Jul.18: 192.41.177.125 1:23:29 mae-east.nsn.nasa.gov Jul.18: 192.41.177.251 0:59:05 mae-east-rt1.es.net Jul.18: 192.41.177.241 0:08:56 sl-mae-e-F0/0.sprintlink.net Here's a list giving the number of disconnects (where there were 5 or more disonnects per day). The majority of flapping seems to be at Mae-East and Mae-West. date peer hits Jul 18 192.157.69.250 8 rs1.sprint.ra.net NY NAP Jul 18 192.41.177.125 72 mae-east.nsn.nasa.gov MaeE Jul 18 192.41.177.251 34 mae-east-rt1.es.net MaeE Jul 18 192.41.177.252 56 mae-east-rt2.es.net MaeE The July 18 problem was mostly concentrated over one 3.5 hour period of continuous flap. Jul 18 07:19:28 to Jul 18 10:52:30 (122:47 / 213:02) 192.41.177.125 took 50 hits (57:00) 192.41.177.252 took 41 hits (62:31) 192.41.177.251 took 17 hits (34:19) Any clues from NASA and ESNET as to why this instability occurred at Mae-east? Was this some form of BGP meltdown or just hardware trouble at or getting to the Mae? Curtis

2 1

None
by Allwyn Crichlow 20 Jul '95

20 Jul '95

2 1

send info
by Allwyn Crichlow 20 Jul '95

20 Jul '95

send info

1 0

broken glue in .net domain
by Michael Dillon 19 Jul '95

19 Jul '95

We are attempting to get the Internic to change our secondary nameserver for the junction.net domain but not having much luck. Our change requests for in-addr.arpa went through in a few days. But the Internic rejected the first request saying we needed to use a new form. So we resubmitted but it is now almost two weeks ago. What is the point of a new form if we cannot get things updated any faster? Then we noticed that DNS to our new secondary nameserver ns2.bc.net was acting wierd. So we dug into the .net domain and discovered several A records with the WRONG IP ADDRESS. I don't know whether it was a typing error at the Internic or whether somebody at BC.NET screwed up, but why do changes like this take so long if nobody even verifies such a simple and obvious thing? You can see this by trying the whois command on sno.net, infoserve.net or concordpacific.net Compare the IP address for ns2.bc.net with the one given by nslookup when talking to an authoratative server for the domain like jade.bc.net In addition there is at least one glue record for ns1.bc.net which erroneously reports its IP address to be 128.198.4.1 which is also wrong since ns1 is the same as jade.bc.net Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com michael(a)junction.net

1 0