June 1998 - Test - lists.nanog.org

Re: smurf amp nets
by shields＠crosslink.net 13 Jun '98

13 Jun '98

In article <Pine.LNX.3.95.980613100514.4911B-100000(a)uplift.sparta.lu.se>, Mikael Abrahamsson <swmike(a)swm.pp.se> wrote: > I think the only way to solve this more permanently is to remove the > response of ICMP data to broadcast adresses in the OS. Is anyone > preassuring for this to happen? Is there a list of OS that actually does > respond to ICMP to broadcast adresses? Most of them do, because otherwise people complain about simpleminded network autodiscovery tools not working. That's the same complaint people made about directed broadcasts so I think that after a few people suffer from cracked machines launching attacks at undirected broadcasts, those will get turned off too. Here is a trivial patch against Linux 2.0.34. And disable your echo/chargen ports. UDP works as well as ICMP. Index: kernel-source/net/ipv4/icmp.c diff -u kernel-source/net/ipv4/icmp.c:1.1.1.2 kernel-source/net/ipv4/icmp.c:1.2 --- kernel-source/net/ipv4/icmp.c:1.1.1.2 Thu Jun 11 01:18:53 1998 +++ kernel-source/net/ipv4/icmp.c Thu Jun 11 04:05:46 1998 @@ -1108,20 +1108,13 @@ /* * RFC 1122: 3.2.2.6 An ICMP_ECHO to broadcast MAY be silently ignored (we don't as it is used * by some network mapping tools). + * [But I've decided to ignore it anyway. --Shields 1997-07-22] * RFC 1122: 3.2.2.8 An ICMP_TIMESTAMP MAY be silently discarded if to broadcast/multicast. */ if (icmph->type != ICMP_ECHO) - { icmp_statistics.IcmpInErrors++; - kfree_skb(skb, FREE_READ); - return(0); - } - /* - * Reply the multicast/broadcast using a legal - * interface - in this case the device we got - * it from. - */ - daddr=dev->pa_addr; + kfree_skb(skb, FREE_READ); + return(0); } len-=sizeof(struct icmphdr); -- Shields, CrossLink.

1 0

smurf amp nets
by Jon Lewis 13 Jun '98

13 Jun '98

I just recorded 4.5mb of a smurf attack directed at one of my servers. Here's a list of the networks used as amplifiers and the number of different hosts responding from each network. If you received this message and did not get it via the NANOG mailing list (or received multiple copies of this message), then you are listed with an IP registry as being the maintainer of one of the networks near the top of the list below. If you do no know what smurf is or why being a smurf amplifier is bad, please read http://www.quadrunner.com/~chuegen/smurf.txt. By continuing to be a smurf amplifier, you will risk portions of the Internet cutting off connectivity to your network, and may provoke attacks on your networks or hosts. 207.164.49: 87 205.68.128: 80 131.179.96: 63 206.39.81: 58 207.137.77: 46 207.123.94: 41 208.133.51: 33 207.141.205: 31 205.225.15: 29 206.39.75: 27 193.118.192: 26 192.208.46: 24 204.163.200: 23 207.102.100: 23 194.153.0: 23 194.72.186: 19 194.205.4: 19 195.224.29: 19 194.193.110: 19 192.86.78: 18 207.141.179: 17 207.204.135: 17 164.38.16: 17 193.117.190: 16 192.149.109: 16 207.87.98: 16 194.238.48: 16 204.215.181: 15 195.216.16: 15 205.225.30: 15 209.36.0: 14 195.188.206: 14 199.95.207: 14 144.85.10: 14 193.164.172: 14 198.82.184: 13 198.76.172: 13 207.243.60: 13 204.249.16: 12 140.222.56: 12 195.166.32: 12 129.210.8: 12 205.184.109: 12 207.243.45: 12 205.226.153: 12 128.11.27: 12 194.73.141: 12 206.28.165: 11 207.141.24: 11 193.115.32: 10 207.243.15: 10 204.164.100: 10 204.97.148: 10 204.107.162: 10 198.76.181: 10 194.88.77: 10 128.11.24: 10 199.242.245: 9 206.243.214: 9 198.112.240: 9 205.232.33: 9 207.233.86: 9 204.107.163: 9 206.39.78: 8 206.39.79: 8 206.119.82: 8 208.133.50: 8 140.89.18: 7 204.250.54: 7 206.39.82: 7 207.141.96: 7 192.65.144: 7 207.60.44: 7 205.225.27: 7 193.123.31: 7 164.38.19: 7 140.89.16: 6 164.67.128: 6 206.105.235: 6 206.105.236: 6 206.105.238: 6 205.181.168: 6 207.121.155: 6 129.210.11: 6 4.1.107: 6 192.216.247: 6 194.72.123: 6 207.121.91: 6 205.181.101: 6 207.243.240: 6 205.244.34: 6 207.236.112: 6 205.227.44: 6 207.87.20: 5 206.105.239: 5 207.28.162: 5 206.149.201: 5 199.240.110: 5 207.28.174: 5 166.77.235: 5 205.225.26: 5 206.119.169: 5 199.251.133: 5 207.120.147: 5 128.173.100: 4 206.39.72: 4 206.39.76: 4 207.28.163: 4 206.149.204: 4 162.127.7: 4 204.119.165: 4 207.0.88: 4 207.0.91: 4 205.218.18: 4 164.38.17: 4 164.38.18: 4 206.39.93: 3 206.149.228: 3 206.149.229: 3 195.216.24: 3 205.225.28: 3 207.233.88: 3 193.164.160: 3 205.226.152: 3 194.88.75: 3 209.178.0: 2 207.244.95: 2 194.126.66: 2 206.39.77: 2 206.34.74: 2 207.155.151: 2 206.149.208: 2 206.34.80: 2 172.16.99: 2 164.67.160: 2 206.34.91: 2 154.32.18: 2 204.167.134: 2 4.1.25: 2 12.127.147: 2 131.192.100: 2 207.21.26: 2 206.85.107: 2 206.250.100: 2 207.242.71: 2 209.155.16: 2 206.34.100: 2 206.34.101: 2 194.51.203: 2 195.92.210: 2 144.85.14: 2 193.164.161: 2 205.244.33: 2 195.200.12: 2 207.122.94: 2 207.240.2: 2 206.34.46: 1 195.50.72: 1 193.115.33: 1 128.97.251: 1 206.105.227: 1 164.38.32: 1 4.1.1: 1 206.105.231: 1 194.247.64: 1 206.39.70: 1 199.93.199: 1 144.85.200: 1 194.154.13: 1 137.52.109: 1 165.113.56: 1 144.85.207: 1 206.34.78: 1 206.98.32: 1 12.127.114: 1 128.97.46: 1 205.125.0: 1 157.130.0: 1 195.5.1: 1 206.39.92: 1 206.39.94: 1 206.39.98: 1 204.70.226: 1 12.127.209: 1 205.68.129: 1 205.202.164: 1 206.34.95: 1 204.59.1: 1 195.15.6: 1 195.89.160: 1 207.60.45: 1 195.89.163: 1 193.118.193: 1 204.70.164: 1 128.97.79: 1 4.0.128: 1 154.32.26: 1 195.99.124: 1 192.221.137: 1 4.0.63: 1 4.0.64: 1 12.127.232: 1 194.177.180: 1 144.85.1: 1 4.0.132: 1 194.80.132: 1 4.0.135: 1 206.41.10: 1 166.48.6: 1 137.39.135: 1 207.123.112: 1 196.7.77: 1 131.32.39: 1 209.4.206: 1 166.77.10: 1 204.119.168: 1 194.74.17: 1 207.165.237: 1 255.255.255: 1 12.127.163: 1 207.87.97: 1 4.0.144: 1 12.127.37: 1 149.142.122: 1 207.140.148: 1 4.0.80: 1 196.7.126: 1 192.216.246: 1 195.166.6: 1 207.0.84: 1 131.192.31: 1 131.192.32: 1 12.127.177: 1 207.233.85: 1 12.127.179: 1 204.97.134: 1 149.142.76: 1 169.139.60: 1 193.36.37: 1 4.1.66: 1 207.0.90: 1 206.149.195: 1 12.127.180: 1 207.217.50: 1 207.123.29: 1 4.0.240: 1 4.0.160: 1 194.72.131: 1 195.92.201: 1 128.97.113: 1 137.145.112: 1 207.68.13: 1 198.247.230: 1 194.205.68: 1 195.232.0: 1 157.130.193: 1 172.16.0: 1 172.16.1: 1 194.38.93: 1 131.119.18: 1 4.0.182: 1 192.221.96: 1 131.119.26: 1 131.119.28: 1 12.127.81: 1 128.97.147: 1 12.127.83: 1 164.67.72: 1 131.119.36: 1 131.119.38: 1 204.59.224: 1 128.97.230: 1 193.118.200: 1 194.164.1: 1 194.88.82: 1 131.119.49: 1 207.240.1: 1 207.137.76: 1 205.182.0: 1 ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

8 10

Terminology for replication
by Howard C. Berkowitz 13 Jun '98

13 Jun '98

In determining customer requirements for "multihomed" or generic high-availability services, I often find there is a major terminology problem. Customer expectations may not be met because they are using "cache" or "mirror" differently than an ISP person. After the April IETF meeting, Jacob Palme posted to the general IETF mailing list what I tink is an excellent start on the problem. There was almost no response, other than a comment or two that different application communities use the terms differently. Perhaps these issues would be more of interest in NANOG, because I think they are very operational at the requirements definition end. Unless a more useful place to collect comments emerges, I'd like to record the consensus in my I-D on multihoming requirements, currently http://www.ietf.org/internet-drafts/draft-berkowitz-multirqmt-01.txt My thoughts would to be to get one more round of comments, see if the IETF Operations Area wants to consider it, and if not send it to the IESG as an individual contribution in a month or two. The subject is one of those things that doesn't quite fit the RFC model. ----------- Date: Thu, 2 Apr 1998 15:38:13 +0100 To: IETF general mailing list <ietf(a)ns.ietf.org> From: Jacob Palme <jpalme(a)dsv.su.se> Subject: Terminology for replication What is the correct term for various kinds of replication. Below is a proposal as a basis for a discussion. Function Proposed term -------------------------------------------------------+------------------- A general term for all kinds of copying of identical Replication to several stores. Replication, where the stores which hold the ori- Mirroring gal knows about where copies are held and periodic (I have also heard automatic updates ensure conformance between mirror the term push- copies and the original. caching) Replication, where a store saves a copy of a docu- Caching ment which it happens to get, without 100 % safe methods against outdated objects in the cache. Caching with some added facilities, such as Controlled caching? "Expiry" fields, to reduce the risk of outdated objects in a cache. Replication, where all copies are equally valid, ????? none of them is the "original", as in Usenet News. ------------------------------------------------------------------------ Jacob Palme <jpalme(a)dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme

1 0

Re: smurf amp nets
by Eric McClelland 13 Jun '98

13 Jun '98

On Jun 13, 12:47am, Jon Lewis wrote: > Subject: smurf amp nets > 205.227.44: 6 We've been checking the networks on the posted list, not only for ourselves but for our downstream customers, and attempting contact with customers where necessary to have them configure 'no ip directed-broadcast' or an equivalent. The administrator of the 205.227.44.0/24 network has asked that we post a confirmation that their network has been fixed. Thanks, Eric McClelland GTE Internetworking

1 0

FW: IANA Applications for TLDs
by Jim Fleming 13 Jun '98

13 Jun '98

---------- From: Jim Fleming[SMTP:JimFleming@unety.net] Sent: Saturday, June 13, 1998 6:03 AM To: 'DOMAIN-POLICY(a)LISTS.INTERNIC.NET' Cc: 'dns(a)iia.net.au'; 'tld-wg(a)ripe.net' Subject: IANA Applications for TLDs I suggest that ANY company serious about being a REGISTRY for a Top Level Domain send the following form to <comments(a)iana.org>. This will help to time-stamp people's intentions on the web site. http://www.iana.org/comments-mail/maillist.html 0a. (N)ew (M)odify (D)elete....: New 0b. Auth Scheme................: 0c. Auth Info..................: 1. Comments...................: Application for Top Level Domain 2. Complete Domain Name.......: Organization Using Domain Name 3a. Organization Name..........: 3b. Street Address.............: 3c. City.......................: 3d. State......................: 3e. Postal Code................: 3f. Country....................: Administrative Contact 4a. NIC Handle (if known)......: 4b. (I)ndividual (R)ole........: 4c. Name (Last, First).........: 4d. Organization Name..........: 4e. Street Address.............: 4f. City.......................: 4g. State......................: 4h. Postal Code................: 4i. Country....................: 4j. Phone Number...............: 4k. Fax Number.................: 4l. E-Mailbox..................: Technical Contact 5a. NIC Handle (if known)......: 5b. (I)ndividual (R)ole........: 5c. Name (Last, First).........: 5d. Organization Name..........: 5e. Street Address.............: 5f. City.......................: 5g. State......................: 5h. Postal Code................: 5i. Country....................: 5j. Phone Number...............: 5k. Fax Number.................: 5l. E-Mailbox..................: Billing Contact 6a. NIC Handle (if known)......: 6b. (I)ndividual (R)ole........: 6c. Name (Last, First).........: 6d. Organization Name..........: 6e. Street Address.............: 6f. City.......................: 6g. State......................: 6h. Postal Code................: 6i. Country....................: 6j. Phone Number...............: 6k. Fax Number.................: 6l. E-Mailbox..................: Prime Name Server 7a. Primary Server Hostname....: 7b. Primary Server Netaddress..: Secondary Name Server(s) 8a. Secondary Server Hostname..: 8b. Secondary Server Netaddress: Jim Fleming Unir Corporation - http://www.unir.com 1998 - The Year of the C+@ IS Coordinator for the AM Radio Station Registry - http://www.DOT.AM

1 0

Every Active Member Deserves A Paycheck!
by XE28q6ol4＠oprai11ders.com 13 Jun '98

13 Jun '98

Every Active Member Deserves A Paycheck! No Sponsoring Required To Get A Paycheck! ***The True Network Marketers Dream.*** Simple And Unbelievably Lucrative! Click Here For More Information> http://www.gwc1.com/members/fd79/gwc1.htm To be removed - remove58(a)hotmail.com or call 904-282-0945

1 0

The Cidr Report
by Tony Bates 12 Jun '98

12 Jun '98

This is an auto-generated mail on Fri Jun 12 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 12Jun98 0) General Status Table History ------------- Date Prefixes 050698 50625 060698 51451 070698 51501 080698 51191 090698 51499 100698 51418 110698 51862 120698 51404 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3625 Number of ASes announcing only one prefix: 1735 (917 cidr, 818 classful) Largest number of cidr routes: 357 announced by AS3561 Largest number of classful routes: 1128 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Jun98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 463 240 223 48.2% IMCI AS2493 501 291 210 41.9% iSTAR Internet, Inc. AS3602 506 313 193 38.1% Sprint Canada Inc. AS1740 545 353 192 35.2% CERFnet AS701 1128 939 189 16.8% Alternet AS3749 220 65 155 70.5% TECNET AS174 728 583 145 19.9% Performance Systems International AS4262 213 125 88 41.3% CERFnet Los Angeles SMDS AS3221 112 42 70 62.5% EENet Autonomous System AS4755 98 31 67 68.4% Videsh Sanchar Nigam Ltd. India AS10928 109 43 66 60.6% UNKNOWN AS7046 207 142 65 31.4% UUNET-CUSTOMER AS5668 114 49 65 57.0% Century Telephone Inc. AS3804 206 144 62 30.1% Bell Solutions AS271 113 54 59 52.2% BCnet Backbone AS1221 289 233 56 19.4% AARNET-AS AS549 205 152 53 25.9% ONet Backbone AS4740 375 323 52 13.9% ASN-OZEMAIL (Ozemail Pty Ltd) AS4539 74 24 50 67.6% NETROPOLIS AS72 85 37 48 56.5% Schlumberger Information Network AS6335 68 20 48 70.6% NTRNET AS8517 122 75 47 38.5% ULAKNET-ASN AS4200 148 101 47 31.8% AGIS (Apex Global Information Ser AS1239 541 494 47 8.7% SprintLink Backbone AS852 159 118 41 25.8% AGT Advance Communication AS7657 122 84 38 31.1% The Internet Group Limited AS762 115 78 37 32.2% WELLFLEET-AS AS719 443 406 37 8.4% LANLINK autonomous system AS6181 65 28 37 56.9% FUSE-NET AS803 72 36 36 50.0% SaskNet Backbone For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

True Cost of Firewalling
by Ben Kirkpatrick 12 Jun '98

12 Jun '98

Has anyone done a good comparison recently of the packet forwarding speeds of suns and ciscos? Sure it seems easier to front-end a sun and use it as a firewall, but how well can a sun forward ip? Thanks, Ben Kirkpatrick Data Engineering ELI Corporate HQ Third Floor 4400 NE 77th Avenue Vancouver, WA 98662 desk 360.816.3508 pager 888.997.8363

3 2

Re: gated
by Paul Vixie 12 Jun '98

12 Jun '98

peter(a)wonderland.org (Peter Galbavy) writes: > Once I thought the GPL a virus and evil, but with the recent > profiliation of previously free software becoming hijacked and > used for profit *and still claiming to be the definitive source > for the software* is getting tiresome. gated and X11 are two > examples of this. What next ? How muuch of >your< code is > being sold by others claiming to own it ? all of it. the amazing part is when folks remove the copyrights and authorship credits, even though the copyrights just specify that the copyrights shall not be removed and that i not be sued -- there are no other restrictions in rtty, bind, cron, or even my little libraries like bitstring and avltree. i've twice now been hired as a consultant by companies who were, unknowingly it seemed, including my code in their products after editing out the original copyrights and credits. (in one case i was paid to fix a bug in code the payor didn't know was originally mine.) but you know what? i'm flattered. all that hype about how commercial grade code can only come from strong engineering companies with good funding, real management, and so on -- and there's my code at the heart of a couple of products i won't mention here, with my name ripped out. seeing my code used in this way just tells me that i don't charge enough when i'm out consulting. and for the record, i still think the GPL is very evil. and also for the record, we're commercializing BIND since i'm no longer able to fund it out of my own pocket (my pocket is now empty) and we ended up not getting the kind of donations we needed as a nonprofit. while i'm committed to keeping a freely redistributable version and to shipping source code, i've got to be realistic about my mortgage payment and the lack of speed and quality of BIND's evolution when it can only get worked on by volunteers. in that sense i very much applaud what the merit folks have done with gated, and what the sendmail,inc. guys are doing with sendmail. > I think we should now disappear, since this is NANOG and this thread > is not quite an operational issue. Yet. as a coauthor of RFC 2010 and as the specific author of section 2.1, i don't agree. reference implementations with widely reviewable source code are THE reason that the internet can be "operated" at all. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

4 4

Re: So... what's the best routing solution for..
by John Fraizer 12 Jun '98

12 Jun '98

At 02:07 AM 6/12/98 -0400, you wrote: > >He said this was an ethernet handoff from the isp; they are not simply >going to plug him into a switch; he will most likely get a port on a >cisco; they should be able to apply policies for him.. no? > >I don't see why he even needs a router, unless there is a lack of a trust >of the upstream's ability to filter.. Or if you know beforehand they will >not? Depending on his upstream, the ethernet connection he gets may be off of one of their backbone routers. In that case, it would not be wise for them to load it up with filters for each client. Let it do it's job as a backbone router and have the customer get a 2514 or a *nix box with some sort of firewall util. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0