- ripe-list - mailman.ripe.net

RIPE NCC Staff Position: Junior Hostmaster (3 days/week)
by Daniel Karrenberg 24 Jul '95

24 Jul '95

Please distribute this announcement to all possibly interested parties. Thank you Daniel Karrenberg RIPE NCC Manager ------------------------------------------------------------------ RIPE: Coordinating the Internet in Europe. Due to the continuing explosive growth of the European Internet there is an immediate opening at the RIPE NCC for a J u n i o r H o s t m a s t e r for 3 days (24 hours) per week. Every host directly connected to the Internet needs an address. NCC hostmasters play a key role in the distribution of the Internet address space throughout Europe. Duties The general duties NCC hostmasters comprise: - to handle all address space related requests - to help maintain the databases the RIPE NCC keeps - to propose new activities, where needed - to report to the RIPE NCC Manager The specific duties of the junior hostmaster are: - to allocate address space to local Internet registries - to support local registries where needed - to assign address space - to review assignments made by other registries - to answer address space related queries - to refer non-routine requests to appropriate senior staff Almost all communications with customers and other organisations involved in Internet address space assignment is via the Internet itself. The position provides an excellent opportunity to work at the very heart of the European Internet industry. Qualifications Essential - willingness to learn quickly about the Internet environment - ability to perform administrative tasks reliably - good knowledge of written and spoken English - good communication skills - ability to learn and use Unix and X-windows based computer tools Desirable - work experience in an international environment - previous exposure to the Internet - basic experience with Unix and X-windows based computer tools The position is suitable both for those with administrative skills willing to learn about the Internet and to recent graduates with Internet experience willing to do administrative work. Female applicants and applicants from all European countries are explicitly encouraged. Depending on their ambitions and abilities junior hostmasters can be promoted to senior positions at the NCC. R I P E RIPE (Reseaux IP Europeens) is a collaborative organisation open to all European Internet service providers. The objective of RIPE is to ensure the necessary administrative and technical coordination to allow the operation of a pan- European IP network. RIPE does not operate a network of its own. RIPE has been functioning since 1989. Currently more than 80 organisations participate in the work. The result of the RIPE coordination effort is that the individual end-user is presented on his desk top with a uniform IP service irrespective of the particular network his or her workstation is attached to. In January 1995 1197911 hosts were registered on RIPE coordinated networks. The total number of systems reachable on the Internet worldwide is estimated at almost five million. R I P E N C C The RIPE Network Coordination Centre supports all those RIPE activities which cannot be effectively performed by volunteers from the participating organisations. Besides supporting RIPE activities in general the NCC provides the following services to network operators: o NETWORK MANAGEMENT DATABASE containing information about address space, routing, DNS domains and contact persons o DELEGATED INTERNET REGISTRY a clearing house distributing IP address space o RIPE INTERNET ROUTING REGISTRY o RIPE DOCUMENT STORE o RIPE INTERACTIVE INFORMATION SERVICE A detailed description of these activities can be found in the RIPE NCC Activity Plan (document ripe-110). This document can be obtained from the RIPE document store. The RIPE NCC is currently staffed as follows: one NCC manager two senior hostmasters (one more is being hired) one junior hostmaster (two more have already been hired) one NCC administrative staff In addition there is a conscienscious objector performing administrative duties. A deputy manager will also be hired this year. The NCC is funded by all Internet service providers in Europe who operate local Internet registries. NCC staff are formally employed by TERENA. TERENA TERENA is the European Association of research networking organisations and their users. TERENA has been created by a merger of the RARE and EARN associations. TERENA carries out technical activities and provides a platform for discussion and education to encourage the development of a high-quality computer networking infrastructure for the European research community. Conditions RIPE NCC personnel is employed by the TERENA association under their standard employment conditions. The salary will depend on qualifications and experience. Costs of relocation to the Netherlands will be met. The open position is part time for 24h/week on three working days. The distribution of the time over the week can be discussed. The appointment will be for one year with possible extension. Location The RIPE NCC is located at the Scientific Center Watergraafsmeer (WCW) in Amsterdam. The offices will be situated at NIKHEF, the Dutch National Institute for Nuclear Physics and High Energy Physics. Further Information For further information about the RIPE NCC, please see the RIPE document store at http://www.ripe.net/ ftp://ftp.ripe.net/ gopher://gopher.ripe.net/ telnet://info.ripe.net/ For further information about this position please contact: Daniel Karrenberg RIPE NCC Manager Kruislaan 409 NL-1098 SJ Amsterdam Netherlands Tel.: +31 20 592 5065 <Daniel.Karrenberg(a)ripe.net> How to Apply Applications, including a CV and references should be submitted in confidence to the address above and should be received no later than Sunday August 13th 1995.

1 0

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

In Memoriam
by Miroslav Ruda 12 Jul '95

12 Jul '95

We regret to inform you that Ivos Cernohlavek tragically died on Monday, July 10, following a boating accident in Norway. Ivos, one of the main developers of the Czech Educational and Scientific Network, significantly helped to improve the computing capabilities of many people throughout the Czech Republic. We will miss him immensely. Mirek Ruda (ruda(a)ics.muni.cz)

1 0

Wanted at the RIPE NCC: Senior Hostmaster
by Daniel Karrenberg 07 Jul '95

07 Jul '95

Please distribute this announcement to all possibly interested parties. Thank you Daniel Karrenberg RIPE NCC Manager RIPE: Coordinating the Internet in Europe. Because one of our staff moves on to a major Internet service provider there is an immediate opening at the RIPE NCC for a Senior Hostmaster Every host directly connected to the Internet needs an address. NCC hostmasters play a key role in the distribution of the Internet address space throughout Europe. Duties The general duties NCC hostmasters comprise: - to handle all address space related requests - to help maintain the databases the RIPE NCC keeps - to propose new activities, where needed The specific duties of the vacant position: - to deal with non-routine address space requests - to support local registries where needed - to review assignments made by other registries - to liaise with other senior staff about registry matters - to supervise and support junior staff - to help provide training local registries - to take resoponsibility for one or more other NCC activities The senior hostmaster reports to the NCC manager. Almost all communications with customers and other organisations involved in Internet address space assignment is via the Internet itself. The position provides an excellent opportunity to work at the very heart of the European Internet industry. Qualifications Essential - sound engineering knowledge about the Internet - experience with operating Internet networks - experience with Unix and X-windows based computer tools - ability to perform administrative tasks reliably - good knowledge of written and spoken English - good communication skills Desirable - work experience in an international environment - experience with Internet service provision Female applicants and applicants from all European countries are explicitly encouraged to apply. Depending on their ambitions and abilities senior hostmasters can be promoted to more senior positions at the NCC. R I P E RIPE (Reseaux IP Europeens) is a collaborative organisation open to all European Internet service providers. The objective of RIPE is to ensure the necessary administrative and technical coordination to allow the operation of a pan- European IP network. RIPE does not operate a network of its own. RIPE has been functioning since 1989. Currently more than 80 organisations participate in the work. The result of the RIPE coordination effort is that the individual end-user is presented on his desk top with a uniform IP service irrespective of the particular network his or her workstation is attached to. In May 1995 1463816 hosts were registered on RIPE coordinated networks. The total number of systems reachable on the Internet worldwide is estimated at more than five million. R I P E N C C The RIPE Network Coordination Centre supports all those RIPE activities which cannot be effectively performed by volunteers from the participating organisations. Besides supporting RIPE activities in general the NCC provides the following services to network operators: o NETWORK MANAGEMENT DATABASE containing information about address space, routing, DNS domains and contact persons o DELEGATED INTERNET REGISTRY a clearing house distributing IP address space o RIPE INTERNET ROUTING REGISTRY o RIPE DOCUMENT STORE o RIPE INTERACTIVE INFORMATION SERVICE A detailed description of these activities can be found in the RIPE NCC Activity Plan (document ripe-110). This document can be obtained from the RIPE document store. The RIPE NCC is currently staffed by 9 full time employees: one NCC manager three senior hostmasters four junior hostmasters (2 of which starting in August) one administrative staff The NCC is funded by all Internet service providers in Europe who operate local Internet registries. NCC staff are formally employed by TERENA. TERENA TERENA is the European Association of research networking organisations and their users. TERENA has been created by a merger of the RARE and EARN associations. TERENA carries out technical activities and provides a platform for discussion and education to encourage the development of a high-quality computer networking infrastructure for the European research community. Conditions RIPE NCC personnel is employed by the TERENA association under their standard employment conditions. The salary will depend on qualifications and experience. Costs of relocation to the Netherlands will be met. The appointment will be for one year with possible extension. Location The RIPE NCC is located at the Scientific Center Watergraafsmeer (WCW) in Amsterdam. The offices will be situated at NIKHEF, the Dutch National Institute for Nuclear Physics and High Energy Physics. Further Information For further information about the RIPE NCC, please see the RIPE document store at http://www.ripe.net/ ftp://ftp.ripe.net/ gopher://gopher.ripe.net/ telnet://info.ripe.net/ For further information about this position please contact: Daniel Karrenberg RIPE NCC Manager Kruislaan 409 NL-1098 SJ Amsterdam Netherlands Tel.: +31 20 592 5065 <Daniel.Karrenberg(a)ripe.net> How to Apply Applications, including a CV and references should be submitted in confidence to the address above and should be received no later than Sunday July 23rd 1995. Applications by electronic mail are perfectly acceptable. We accept plain ASCII or PostScript. All applications by e-mail will be acknowledged.

1 0

RIPE DNS hostcount for June 1995
by Mirjam Kuehne 05 Jul '95

05 Jul '95

Dear all, Here is the hostcount for June 1995. After the first quarter of 1995 was quite turbulent, the numbers are now pretty stable again. The table shows an increase since last month of over 87,000 (or 5.9%) to a total of over 1,550,000 hosts in the DNS in Europe. This comes to a total increase of 16.9% during the last three month. Germany shows the highest increase for June with over 20,000 hosts. The hostcount can also be found under ftp.ripe.net/ripe/hostcount. Kind regards, Mirjam Kuehne RIPE NCC RIPE DNS Hostcount Previous Count : Wed May 31 1995 This Count : Fri Jun 30 1995 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 3 0 0 0 0 am 3 47 1 46 + 22 at 746 40226 822 39404 + 2035 az 3 16 0 16 0 be 612 24316 865 23451 + 3075 bg 47 644 36 608 + 20 by 1 5 0 5 + 3 ch 569 63617 536 63081 + 4622 cy 13 155 5 150 + 67 cz 264 15056 260 14796 + 16 de 3708 362094 13885 348209 +20209 dk 457 36641 613 36028 + 3810 dz 2 16 0 16 + 3 ee 95 2411 22 2389 + 300 eg 6 170 2 168 0 es 726 39314 606 38708 + 1399 fi 844 110753 2025 108728 + 5454 fo 13 470 0 470 0 fr 1659 113136 2117 111019 + 1984 gb 1 28 0 28 0 ge 1 0 0 0 0 gr 246 5608 449 5159 + 1018 hr 81 1831 150 1681 - 158 hu 150 11553 214 11339 + 2063 ie 164 8225 122 8103 - 481 il 375 19203 625 18578 + 1653 is 119 6769 65 6704 + 517 it 1493 48871 2710 46161 + 2983 li 5 22 2 20 + 3 lt 27 265 2 263 + 18 lu 70 1488 16 1472 + 258 lv 25 845 25 820 - 53 ma 1 0 0 0 0 mk 6 29 0 29 + 27 mt 1 0 0 0 0 nl 982 120763 1905 118858 + 3453 no 1175 69082 3001 66081 + 2528 pl 562 16722 1453 15269 + 912 pt 208 8339 98 8241 + 834 ro 33 729 15 714 + 27 ru 234 4059 312 3747 + 509 se 1469 110061 3376 106685 +11765 si 105 2947 66 2881 - 2 sk 94 2201 44 2157 + 180 su 324 7904 383 7521 + 384 tn 3 73 6 67 + 8 tr 112 3539 90 3449 + 162 ua 107 1638 335 1303 + 123 uk 4547 354654 28756 325898 +15537 va 0 0 0 0 0 yu 3 0 0 0 0 ============================================================ 22494 1616535 66015 1550520 +87287

1 0

IMPROTANT: RIPE22 date change
by RIPE NCC Staff 04 Jul '95

04 Jul '95

Due to accomodation problems, the date of the 22nd RIPE meeting had to be changed from 2-4 October to 11-13 October. We apalogise for any inconvenience this may cause. There is no official announcement for RIPE22 out yet, but this seemed important enough to note already. Kind regards, Roderik Muit RIPE NCC

1 0

Re: New Document available: ripe-127
by christian.huitema＠sophia.inria.fr 03 Jul '95

03 Jul '95

A (At) 11:39 AM 30/6/95 +0200, RIPE NCC Document Annoucement Service ecrivait (wrote): >Content-Type: text/plain; charset="us-ascii" >Content-Description: Document Announcement > > >New/Revised RIPE Document Announcement >-------------------------------------- >A revised/new document is available from the RIPE document store. > >Ref: ripe-127 > >Short content description >------------------------- > >The RIPE NCC receives an increasing amount of questions >about the protability or provider independence >of address space. This document provides guidance to European Internet >registries concerning these issues. > Given that interest for these matters spreads well outside Europe, could you please consider submitting this as an informational RFC? Christian Huitema

2 1

New Document available: ripe-127
by RIPE NCC Document Annoucement Service 30 Jun '95

30 Jun '95

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-127 Title: Provider Independent vs Provider Aggregatable Address Space Author: Daniel Karrenberg, RIPE NCC Date: 30 Jun 1995 Format: PS=91858 TXT=17620 Obsoletes: Obsoleted by: Updates: ripe-126 Updated by: Old: Short content description ------------------------- The RIPE NCC receives an increasing amount of questions about the protability or provider independence of address space. This document provides guidance to European Internet registries concerning these issues. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-127.txt for the ASCII version ripe-127.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-127.txt

1 0

Heads-Up! (INFO#95.16723)
by Thomas Longstaff 29 Jun '95

29 Jun '95

-----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii ============================================================================= Heads-Up to Network Service Providers - IP Spoofing Attacks CERT Coordination Center June 29, 1995 ============================================================================== 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 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. 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 .............................................................................. CERT Public Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi2a4WoAAAEEAN0IPkqCmoGRud0Kts3g4ZGgZ4zyqY8C5VTOgUcqU+D2U1so 21K6dxj/lewKFduXtNpqDeg6C0wR6GIMJ2jWLU4GUEq0xHohioWGGg5O3QTvCpN3 rnLIKO9urv4Wjgkp1n1ys7xcOYl5jb7kuhdlXs3kNgKi4zBB5XVP+x0t4w7BAAUR tChDRVJUIENvb3JkaW5hdGlvbiBDZW50ZXIgPGNlcnRAY2VydC5vcmc+iQCVAgUQ LZrkOXVP+x0t4w7BAQEI3QP/d9gl7GD52Pd8KbsBMb0hiploigL8kZW1Q1fVsIm1 cO9xumU89CLf2jrN+IdrIMpVWAO3DyJjZooZTaJBg/9jjv3HltHTq/XFD5c+WYlM G+fQZVuR8qu8+D8P8pPbNVm94wxj9fyKO39/dnub1UfjDedJBtt+zgMJmstADkOv QBM= =N6E5 - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBL/MOmHVP+x0t4w7BAQF7+QQAp8mm5Bnu+/wiQK2trEn1JtzV6Ls3Z/gP 1SgZe85eTEGzKvRPKb+G3W7HAFn56B6X6JCgixl0Xgj/zcYlOvraug16/DfAd6i0 dkZXcrTQn+GRSHbi6oXPs5FRCE0eE5tFkhouVnROECBLoKJOR9/0dE4NuLzCkm3Q Uf+x64RmkIs= =RBqe -----END PGP SIGNATURE-----

1 0

hostcount for May 1995
by Mirjam Kuehne 02 Jun '95

02 Jun '95

Dear all, Here comes the hostcount for May 1995. The table shows an increase since last month of more than 80,000 hosts (6.4%) to a total of more than 1,400,000 hosts in the DNS in Europe. I wonder if we will hit the 1.5 million boundary next month :-) The UK shows the highest increase for May with almost 40,000 hosts more than the month before. This is almost half of the total increase. The hostcount can also be found under ftp.ripe.net/ripe/hostcount. Kind regards, Mirjam Kuehne RIPE NCC RIPE DNS Hostcount Previous Count : Sun Apr 30 1995 This Count : Wed May 31 1995 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 3 0 0 0 0 am 2 25 1 24 0 at 727 38198 829 37369 + 2292 az 3 16 0 16 0 be 494 21206 830 20376 + 197 bg 43 625 37 588 + 182 by 1 2 0 2 0 ch 457 58925 466 58459 0 cy 11 87 4 83 - 46 cz 252 15022 242 14780 + 477 de 3521 340024 12024 328000 +14656 dk 371 32746 528 32218 + 1240 dz 2 13 0 13 + 2 ee 91 2112 23 2089 + 295 eg 6 170 2 168 0 es 675 37913 604 37309 + 2858 fi 787 105358 2084 103274 - 307 fo 13 470 0 470 + 32 fr 1606 110920 1885 109035 +12223 gb 1 28 0 28 0 ge 1 0 0 0 0 gr 220 5193 469 4724 - 88 hr 101 2430 591 1839 + 86 hu 135 9324 48 9276 - 701 ie 143 8710 126 8584 + 101 il 337 17539 614 16925 + 956 is 113 6255 68 6187 + 295 it 1354 46325 3147 43178 + 3077 li 5 17 0 17 + 1 lt 26 247 2 245 + 16 lu 68 1227 13 1214 + 49 lv 28 892 19 873 + 88 ma 1 0 0 0 0 mk 3 2 0 2 + 2 mt 1 0 0 0 0 nl 905 117196 1791 115405 + 2936 no 1086 66465 2912 63553 + 6617 pl 537 15593 1236 14357 + 54 pt 192 7497 90 7407 - 10 ro 27 704 17 687 + 135 ru 192 3482 244 3238 + 438 se 1351 97917 2997 94920 - 1068 si 145 2983 100 2883 + 292 sk 92 2010 33 1977 + 262 su 311 7555 418 7137 + 432 tn 3 65 6 59 + 2 tr 101 3355 68 3287 + 543 ua 106 1399 219 1180 + 155 uk 4245 337203 26842 310361 +39125 va 0 0 0 0 0 yu 3 0 0 0 0 ============================================================ 20898 1525445 61629 1463816 +87896

1 0