- Test - lists.nanog.org

Re: Smurf Amp Nets
by Richard Thomas 20 Jun '98

20 Jun '98

-----Original Message----- From: Karl Denninger <karl(a)mcs.net> To: Vern Paxson <vern(a)ee.lbl.gov> Cc: Andrew Herdman <andrew(a)whine.com>; nanog(a)merit.net <nanog(a)merit.net> Date: Friday, June 19, 1998 9:37 AM Subject: Re: Smurf Amp Nets >On Thu, Jun 18, 1998 at 10:16:38PM -0700, Vern Paxson wrote: >> > 0.0.0.0 >> > 10.0.4.0 >> > 127.0.0.0 >> > 255.255.255.0 >> >> These are pretty cool, I must say. Exactly how does the smurf attacker >> route their echo requests to them? >> >> Vern > >They are straight forged packet flows. Nah those are machines on the relay being used sending those replies. Sometimes from machines given those ips and sometimes from misconfigured networks. I used to have one that would reply 500 times from 10.0.0.1. Just because the broadcast being used is 1.2.3.255 does not mean you will only get packets from 1.2.3.x, and conversely because you receive pings from 1.2.3.x and 1.2.4.x and 1.2.5.x does not necessarily mean there are 3 broadcasts being used. It could easily be only on 1.2.3.255 or even 1.2.69.255 for all you know (and I've seen strange cases of each). This is a complication when you are getting your bcasts from logs of a smurf attack because you never really know where those 10.0.0.0/8's come from, and a complication when you are getting your bcasts from a network scan because you sometimes see huge arrays of broadcasts that are actually just the same hosts being repeated on different broadcasts (ex: you just found 1.2.3.255 - 1.2.203.255 all have 200 dupes each, but closer examination reveals every broadcast returns replies from the same host). Fortunately these problems are even more annoying to the smurf kiddies where it is important to have an accurate estimation of the damage that will be inflicted.

1 0

Definitive documentation for RHWOIS/SWIP
by Howard C. Berkowitz 19 Jun '98

19 Jun '98

Would some kind soul point me to the most recent procedure writeups for RWHOIS and SWIP? I have an assortment of document references, but I'm not sure which is the most recent and definitive. Thanks.

2 2

Government scrutiny is headed our way
by Michael Dillon 19 Jun '98

19 Jun '98

Government scrutiny is headed our way http://www.fcw.com/pubs/fcw/1998/0615/fcw-frontcyber-6-15-1998.html The feds are worried that it is too hard to track down cyber attackers. Although the article doesn't say this explicitly I expect that it won't be long before we see politicians calling for some sort of mandated tracing capabilities between network providers And since IOPS http://www.iops.org/ is hosted by a government funded agency located on the outskirts of DC, I expect that it will be involved in this whole thing. If we could track attacks to their source more quickly, then government would not feel the need to intervene. This may require some changes to router software but unless network operators ask for the changes, the manufacturers will not do it. We need some sort of protocol that will recursively track spoofed source address packets back to their source one hop at a time. Given a destination address the protocol would track it to the previous hop router and recurively initiate the same tracking procedure on that router. Once the attack is tracked to the source, the probe would unroll and report the results to all routers along the probe path for logging or reporting. We have seen that when misconfigured equipment can be quickly identified, such as the smurf amplifiers, then we can apply pressure and get things fixed. Similarly if we can quickly identify the source of a spoofed source address attack then we can apply pressure to get filters in place and have people arrested or secure an insecure machine as the case may be. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael(a)memra.com http://www.memra.com - *check out the new name & new website*

7 13

The Cidr Report
by Tony Bates 19 Jun '98

19 Jun '98

This is an auto-generated mail on Fri Jun 19 12:00:01 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 19Jun98 0) General Status Table History ------------- Date Prefixes 120698 51404 130698 51272 140698 51351 150698 51499 160698 51736 170698 51866 180698 51372 190698 51379 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 213.102.1.0 from AS3259 AS Summary ---------- Number of ASes in routing system: 3657 Number of ASes announcing only one prefix: 1769 (940 cidr, 829 classful) Largest number of cidr routes: 353 announced by AS3561 Largest number of classful routes: 1129 announced by AS701 1) Gains by aggregating at the origin AS level --- 19Jun98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 463 242 221 47.7% IMCI AS2493 494 286 208 42.1% iSTAR Internet, Inc. AS3602 507 310 197 38.9% Sprint Canada Inc. AS271 336 145 191 56.8% BCnet Backbone AS701 1129 941 188 16.7% Alternet AS3749 220 65 155 70.5% TECNET AS174 721 582 139 19.3% Performance Systems International AS3218 78 7 71 91.0% AS-RSSI AS3221 112 42 70 62.5% EENet Autonomous System AS5668 117 49 68 58.1% Century Telephone Inc. AS10928 109 43 66 60.6% UNKNOWN AS7046 206 141 65 31.6% UUNET-CUSTOMER AS4755 100 38 62 62.0% Videsh Sanchar Nigam Ltd. India AS3804 205 143 62 30.2% Bell Solutions AS3403 183 125 58 31.7% TIAC AS1221 294 239 55 18.7% AARNET-AS AS549 205 152 53 25.9% ONet Backbone AS4740 366 316 50 13.7% ASN-OZEMAIL (Ozemail Pty Ltd) AS4200 149 100 49 32.9% AGIS (Apex Global Information Ser AS8517 120 72 48 40.0% ULAKNET-ASN AS72 85 37 48 56.5% Schlumberger Information Network AS4539 73 25 48 65.8% NETROPOLIS AS1239 542 495 47 8.7% SprintLink Backbone AS6335 67 24 43 64.2% NTRNET AS852 158 116 42 26.6% AGT Advance Communication AS719 443 404 39 8.8% LANLINK autonomous system AS762 116 79 37 31.9% WELLFLEET-AS AS6181 65 28 37 56.9% FUSE-NET AS803 72 36 36 50.0% SaskNet Backbone AS4763 108 72 36 33.3% Telstra New Zealand 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

RE: Smurf Amp Nets
by Martin, Christian 19 Jun '98

19 Jun '98

>On Thu, Jun 18, 1998 at 10:16:38PM -0700, Vern Paxson wrote: >> > 0.0.0.0 >> > 10.0.4.0 >> > 127.0.0.0 >> > 255.255.255.0 >> >> These are pretty cool, I must say. Exactly how does the smurf attacker >> route their echo requests to them? >> >> Vern > >They are straight forged packet flows. These also can be situations where layer two devices have private networks mixed in with public networks on the same VLAN. Remember broadcast address translation between layer 3 & 2 through a store-and-forward (or cut-through - any MIN type box will do this) switch will generate MAC layer frames and deliver them out of each port in the VLAN. I know broadcast pings on a Cisco device that is connected to a switch, where the output interface has IP block A, and the VLAN has IP blocks C, D, E, will result in replies from all networks connected to the VLAN, not just the IP block configured on the router. This is why on almost every attack we've seen here, there have been RFC 1918 addresses invlved as amplifiers. Christian

1 0

Re: Out of Office AutoReply: com.tw
by John Fraizer 19 Jun '98

19 Jun '98

At 11:42 AM 6/19/98 -0400, you wrote: >To All: > >I am out of the office until June 23rd In my absence, if your matter is >urgent please call or e-mail or Steven Leibrock x9496, in the GSINet group. Oh, Gawd. Not another misconfigured procmail. ------- 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

Re: com.tw
by John Fraizer 19 Jun '98

19 Jun '98

At 02:06 PM 6/19/98 +0900, you wrote: >thnx John No problem. I'll let the BGP guru's tackle this one though. > >One more big favor... > >Currently our router (AS 4719) believe that > >cisco2#show ip route 210.67.137.27 >Routing entry for 210.67.128.0 255.255.240.0, supernet > Known via "bgp 4719", distance 20, metric 100 > Tag 4673, type external > Last update from 202.235.64.29 6d02 ago > Routing Descriptor Blocks: > * 202.235.64.29, from 202.235.64.29, 6d02 ago > Route metric is 100, traffic share count is 1 > >cisco2#show ip bgp 210.67.137.27 >BGP routing table entry for 210.67.128.0 255.255.240.0, version 1129569 >Paths: (1 available, best #1) > 4673 2516 4637 7483 4783 (aggregated by 4783 10.0.0.1) > 202.235.64.29 from 202.235.64.29 (203.182.16.29) > Origin IGP, metric 100, valid, external, atomic-aggregate, best > >But unfortunately this route does not get to the tw. >traceroute to mail.transcend.com.tw (210.67.137.27), 30 hops max, 40 byte >packets > 1 203.182.192.110 (203.182.192.110) 17.102 ms 1.547 ms 1.443 ms > 2 rlu8-s6.tokyo.mbn.or.jp (202.217.6.57) 21.671 ms 65.388 ms 59.482 >ms > 3 mbgate-f1.tokyo.mbn.or.jp (202.217.2.1) 77.980 ms 59.399 ms 49.818 >ms > 4 202.235.64.20 (202.235.64.20) 17.726 ms 17.756 ms 15.632 ms > 5 203.182.0.186 (203.182.0.186) 27.179 ms 15.962 ms 27.355 ms > 6 210.132.93.29 (210.132.93.29) 21.016 ms 20.923 ms 18.357 ms > 7 tr-ote3.kddnet.ad.jp (210.132.92.7) 39.667 ms 29.826 ms 27.866 ms > 8 210.132.93.186 (210.132.93.186) 86.724 ms 103.435 ms 91.211 ms > 9 f5-1.tmh02.hkt.net (205.252.128.226) 105.295 ms 97.760 ms 74.652 ms >10 * * * >11 highspeede0.hkt.com.tw (202.84.147.242) 140.594 ms 149.499 ms >129.149 ms >12 toSysnet.netplus.net.tw (210.208.255.214) 239.149 ms 214.360 ms >176.328 ms >13 * * * > >and die. > >I need to mess around with BGP, do you have any idea how to put new >BGP route into our router? > > >$B$$$D$b$*@$OC$K$J$C$F$*$j$^$9(B $B$+$o$5$-(B@ giganet$B$G$9!#(B > > > > >$B$+$o$5$-(B >TK3197 > >= = = = = = >Business Network Telecom (BNT) >$B%S%8%M%9%M%C%H%o!<%/%F%l%3%`3t<02q<R(B >$B")(B111-0053$B!!El5~ETBfEl6h@uAp66(B3-8-5 >31$B;35~%S%k(B6$B3,(B >TEL 03-5687-3945 FAX 03-5687-6009 >http://www.giganet.net > >On Fri, 19 Jun 1998, John Fraizer wrote: > >> At 11:58 AM 6/19/98 +0900, you wrote: >> >Does anyone tell me who is in charge of tw domain? >> > >> >For the U.S, could anyone traceroute to >> >mail.transcend.com.tw and send result to me. >> >> [OverKill]:~# traceroute mail.transcend.com.tw >> traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0 >> traceroute to mail.transcend.com.tw (210.67.137.27), 30 hops max, 40 byte >> packets >> 1 eth1-core0.Columbus.EnterZone.Net (209.41.244.1) 0.560 ms 0.400 ms >> 0.377 ms >> 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 0.902 ms >> 3.238 ms 0.753 ms >> 3 aads-nap.att.net (198.32.130.60) 13.383 ms 13.656 ms 13.615 ms >> 4 192.205.31.106 (192.205.31.106) 13.628 ms 14.846 ms * >> 5 12.127.14.70 (12.127.14.70) 66.061 ms 155.938 ms 100.351 ms >> 6 ar2-a300s1.sffca.ip.att.net (12.127.1.141) 64.344 ms 68.834 ms >> 69.998 ms >> 7 12.127.194.118 (12.127.194.118) 222.365 ms 215.204 ms 216.973 ms >> 8 R56-73.seed.net.tw (139.175.56.73) 217.354 ms 223.339 ms * >> 9 192.72.97.134 (192.72.97.134) 286.964 ms 315.482 ms 255.522 ms >> 10 * * r7.sysnet.net.tw (210.67.34.17) 290.594 ms >> 11 n122.n210-67-47-0-24.sysnet.net.tw (210.67.47.122) 627.061 ms 279.038 >> ms 401.041 ms >> 12 mail.transcend.com.tw (210.67.137.27) 395.981 ms 357.553 ms 357.684 ms >> >> >> >> >> >> ------- >> 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... >> >> > > ------- 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

Re: Smurf Amp Nets
by Vern Paxson 19 Jun '98

19 Jun '98

> 0.0.0.0 > 10.0.4.0 > 127.0.0.0 > 255.255.255.0 These are pretty cool, I must say. Exactly how does the smurf attacker route their echo requests to them? Vern

3 2

Re: RBL Update (Re: Lets go vixie!! rbl)
by Dean Anderson 19 Jun '98

19 Jun '98

My apologies. I confused Karl Denninger with Karl Auerbach, who is an attorney. In response to Karl Denninger: At 2:16 PM -0400 6/18/98, Karl Denninger wrote: >Dean, you keep changing your tune. > >First you said *any* spamblocking was illegal. Yes. Any spam blocking when you aren't a party to the email is illegal. Nor is it a departure from anything I have said, previously. So, does this mean you agree that *some* spamblocking is illegal? (I suspect not, but surprise me.) This reads like a political attack. (#25: claim your opponent has waffled, but offer no evidence that anything is different). But I'm not running for any office. My credibility has no relevance to the truth of whether or not 2511 can apply to network providers. Its federal law. Network providers and employees ought to be roughly aware of the laws which apply to them. And certainly not misled. It is obvious now that it can apply. Its also just as clear that there are some legal limitations on what network providers can do with "their equipment". >Now you're looking for someone who is spamblocking IN TRANSIT (ie: not to >or from an end customer). As I have said before, transit providers are clearly not parties to transiting traffic. And I was looking for a Network Service (transit) provider before. >How would THAT come about, pray tell? Do you know how modern SMTP based >email actually *works*? Yes, but apparently you don't. This isn't the only way its handled. Some people "transparently" intercept SMTP. 6 months ago I pointed out UUCP as well. And there is also route filtering via BGP RBL. If they aren't a party to the communication, then its illegal. (like I said before) I'm really disappointed that people keep claiming that 2511 can't possibly apply to a network provider, in spite of the now overwhelming proof to the contrary. But then apparently 2/3s of the democrats think that Clinton didn't screw Monica. And some people think Nixon didn't break any laws. I can't change that sort of blind belief. 6 months ago, I could understand that behavior, since I was offering my opinion based on my reading the text of the statute. It was arguable, and I argued well, I think, but perhaps not well enough. But given the revelations of the 1988 amendment and its hearings, which support my reading of the text, and everything I said 6 months ago and am saying now, I just can't believe there are still people who argue this. At this point, there is nothing to be gained by argument on the applicability of 2511 to network providers. All the evidence is now available, make your own decision. I've brought it to your attention. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

RFC781 timestamp
by Hirohisa TANIGUCHI 19 Jun '98

19 Jun '98

Has anyone tried to get timestamp from routers by RFC781 ip timestamp option? Or is their any tool that utilizes this IP option? I've modified ping progam so that IP timestamp option is set, but: (1) If option flag is set to 3 (i.e. timestamp for only prespecified addresses), it seems all routers simply ignore it. (2) If option flag is set to 1 (i.e. address and timestamp all the way), routers actually do timestamping. Especially when I ping a ROUTER itself with flag=3 timestamp option, with their own address prespecified, no router seems to give their timestamp. But when I ping a HOST (I 've tried Solaris,FreeBSD) it does answer. CISCO documentation says IP timestamp option is implemented, so I'm wondering... bye -- H.Taniguchi (taniguti(a)ntttqn.tnl.ntt.co.jp)

1 0