- Test - lists.nanog.org

Re: NPIC Warning
by Sean Donelan 31 Dec '00

31 Dec '00

On Sat, 30 December 2000, Marshall Eubanks wrote: > List members might be interested in this zombie warning : > > http://www.nipc.gov/warnings/advisories/2000/00-063.htm > > as reported in > http://www.wired.com/news/technology/0,1282,40905,00.html?tw=wn20001230 > > Real threat, or someone seeking funding ? I like the holiday warnings because they often let me know about holidays I never knew existed. They sometimes read a bit like this day in revolutionary history. The problem is every day of the year is important to some group. However, a holiday DDOS attack is a bit of an oxymoron. If a tree falls in a forest.... If no one is using the service over the holiday weekend, is anyone denied? The "pearl harbor" sunday morning attack isn't the best model for DDOS. Rapid distribution of e-mail viruses implies lots of people reading e-mail. Fewer people read e-mail over the holiday weekend suggesting a slower spread of viruses. E-mail viruses spread the fastest during the workday. DDOS attacks are most devestating when network traffic is already near its peak. A truck jackknifed in the middle of rush hour affects a lot more people than an accident on sunday morning. DDOS isn't as effective when there is lots of spare capacity. Collecting zombie computers is mostly a matter of numbers. Since many of the probes are automated, they occur 24 hours a day 7 days a week without regard of holdays or weekends. Of course, that presumes there is some logic or reason for the attack.

1 0

RE: RFC1918 addresses to permit in for VPN? (fwd)
by John Fraizer 31 Dec '00

31 Dec '00

I've been getting flamed by several of you off-list for picking on a "big carrier." As result, I decided to pass this one on to the list. --- John Fraizer EnterZone, Inc ---------- Forwarded message ---------- Date: Sat, 30 Dec 2000 02:56:50 -0500 (EST) From: Wants to keep his job <spork(a)xxxx.com> To: John Fraizer <nanog(a)EnterZone.Net> Subject: RE: RFC1918 addresses to permit in for VPN? Yeah, this "network architect" responded to a post of mine on NANOG that using TAP to send pages was just dumb when I could simply email my pager "directly". Uh... Yeah, that will get my page about "the internet" being down right out to my pager right quick. Of course I didn't see his response for a few weeks, as it fell into my spam folder. Wonder why? xxxx@shell[~]$ telnet 205.152.173.2 25 Trying 205.152.173.2... Connected to ns1.arch.bellsouth.net. Escape character is '^]'. 220 ns1.arch.bellsouth.net ESMTP Sendmail 8.9.1a/8.9.1; Sat, 30 Dec 2000 02:53:06 -0500 (EST) mail from: spammer(a)theinternet.com 250 spammer(a)theinternet.com... Sender ok rcpt to: xxxx(a)xxxx.com 250 xxxx(a)xxxx.com... Recipient ok data 354 Enter mail, end with "." on a line by itself sigh... . 250 CAA02152 Message accepted for delivery quit 221 ns1.arch.bellsouth.net closing connection enough said. flame on... (name deleted) --- Bellsouth: Please patch your spam hole. We all know they'll be using that one now. BTW: Any reason why you have SMTP service on a nameserver available from the global internet Money that tight that you can't have dedicated boxes to do DNS and DNS only? (On the phone to brokers voicemail: "Bellsouth: SELL IT! SELL IT! SELL IT!") --- John Fraizer EnterZone, Inc

5 4

Re: RFC1918 addresses to permit in for VPN?
by Richard A. Steenbergen 30 Dec '00

30 Dec '00

On Sat, 30 Dec 2000, Bill Fumerola wrote: > On Fri, Dec 29, 2000 at 04:19:23PM -0500, Deron J. Ringen wrote: > > > That makes perfect sense to me...there is not a better way to protect a box > > from a DOS/hack than to only give it a private address. Why expose a box > > to the outside world if there is not a need??? > > For exactly this reason, people start to use the reserved address > space as a security feature and think "welp, its safe now!". That should be more correctly stated as "what more simplistic but guarantee of nothing method".., Just remember it only takes one public exploited linux or solaris box on your network, and suddenly all that 1918 space is fair game again. If you have put all your eggs in this one basket and havn't bothered to take care of the rest of your responsabilities, you could quickly find yourself getting bit hard. Straight layer 2 switches provide little protection from someone worming their way through your network, since arp toys like http://www.monkey.org/~dugsong/dsniff/ and dozens of others are now publicly available to script kiddies. I place this in the same category as those who blindly put their faith in the security of ssh, without stopping to think how possible is it that these ssh bins have been backdoored and are logging my passwords and/or connections. This is particularly funny in the terminal room of certain conferences, and the number of people I saw blindly ssh'ing from boxes with no root password at nanog 19 still never ceases to amaze me. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

OT
by John Fraizer 30 Dec '00

30 Dec '00

OK. I'm sorry for flaming the Bellsouths out there. I'll try not to do it any more. --- John Fraizer EnterZone, Inc

1 0

RE: RFC1918 addresses to permit in for VPN?
by John Fraizer 30 Dec '00

30 Dec '00

Oh, come on. You must not monitor NANOG that much. Otherwise, you would know that if I was flaming, anyone with a bell*.* address would be in a burn ward. I was just making a simple observation. Can I help it if every contact I've had, save one, with bell*.* has been a clueless, old-fart, union-so-you-can't-replace-him-her-with-someone-with-clue, wouldn't know a clue if it came up and bit them in the a$%@^$@%^ piece of %^&#%&^#?!??? who is sucking up oxygen from the script kiddies (who while I hate, may actually grow up some day and do something productive)??!!!??? Don't want to be associated with that stereotype? Get rid of 99% of your organization or go to work for someone else. BTW: I know from first hand experience. I had to leave a job at a bell*.* company because as a 19 y/o. I made the 20/30/40/50/60 y/o's nervous as far as their jobs were concerned. 'Nuff said. --- John Fraizer EnterZone, Inc On Fri, 29 Dec 2000, Christian Kuhtz wrote: > > John, > > I disagree with Deron, albeit for different reasons. But I don't think the > flame was neccessary. > > Cheers, > Chris > > -- > Christian Kuhtz <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. > "I speak for myself only." > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > John Fraizer > > Sent: Friday, December 29, 2000 7:01 PM > > To: Deron J. Ringen > > Cc: Simon Lyall; nanog(a)merit.edu > > Subject: RE: RFC1918 addresses to permit in for VPN? > > > > > > > > On Fri, 29 Dec 2000, Deron J. Ringen wrote: > > > > > > > > > -----Original Message----- > > > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > > > Simon Lyall > > > > Sent: Friday, December 29, 2000 3:03 PM > > > > To: nanog(a)merit.edu > > > > Subject: Re: RFC1918 addresses to permit in for VPN? > > > . > > > . > > > > One of the companies we work with has 192.168 address for some of the > > > > radius servers we have to talk to, we are directly connected to them so > > > > it's not a big pain but it's just so ugly. > > > . > > > . > > > That makes perfect sense to me...there is not a better way to > > protect a box > > > from a DOS/hack than to only give it a private address. Why expose a box > > > to the outside world if there is not a need??? > > > > Deron, > > > > Ever heard of an access list? Didn't think so. > > > > > Deron J. Ringen > > > Sr. Network Architect > > > BellSouth Internet Services > > > > Typical. > > > > --- > > John Fraizer > > EnterZone, Inc > > > > > > > > > > >

3 2

EGP/Peering survey
by abha 30 Dec '00

30 Dec '00

Hey Nanog Folks! I've posted my request on many other lists and now it is time to post here.... Please let me know if any of you are interested in participating.... ---------- Hi All! I'm working on gathering some information about how providers interact with each other for a research project. I've compiled a rather lengthy survey that asks questions about peering, peering policy and ISP practices. If you've ever set-up peering policies, etc. for an ISP, I'd love to have your responses to this survey. While answering all questions isn't necessary, I would appreciate it. And I'll be giving T-shirts out to those who complete the whole thing! :) All answers will be kept confidential and will be anonymized and aggregated before being included in any published findings... Anyone here willing to particpate? Drop me a note and I'll send you the survey! Thanks for your help! -abha ;) ps - some of you might've filled out a survey with me at NANOG some time ago, this is actually a follow-up to that one... ;) So, your participation in this round is still appreciated!

2 1

RE: RFC1918 addresses to permit in for VPN? (fwd)
by John Fraizer 30 Dec '00

30 Dec '00

---------- Forwarded message ---------- Date: Fri, 29 Dec 2000 21:54:10 -0500 From: Wants to keep their Job <xxxx(a)bellsouth.net> To: John Fraizer <nanog(a)EnterZone.Net> Subject: RE: RFC1918 addresses to permit in for VPN? Typical, indeed. *sigh* BellSouth. Telco Heads, running Telco Products. Let's squeeze this Internet thing into a two-pound telco bag and hope it doesn't squirt out of the sides... L'idiote de telco... :) I'd take up a collection to buy this guy a clue, but if anyone found out it was a Bell Head, no one would give! At 07:01 PM 12/29/00, you wrote: >On Fri, 29 Dec 2000, Deron J. Ringen wrote: > > > > > > -----Original Message----- > > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > > Simon Lyall > > > Sent: Friday, December 29, 2000 3:03 PM > > > To: nanog(a)merit.edu > > > Subject: Re: RFC1918 addresses to permit in for VPN? > > . > > . > > > One of the companies we work with has 192.168 address for some of the > > > radius servers we have to talk to, we are directly connected to them so > > > it's not a big pain but it's just so ugly. > > . > > . > > That makes perfect sense to me...there is not a better way to protect a box > > from a DOS/hack than to only give it a private address. Why expose a box > > to the outside world if there is not a need??? > >Deron, > >Ever heard of an access list? Didn't think so. > > > Deron J. Ringen > > Sr. Network Architect > > BellSouth Internet Services > >Typical. > >--- >John Fraizer >EnterZone, Inc

1 0

The Cidr Report
by Tony Bates 29 Dec '00

29 Dec '00

This is an auto-generated mail on Fri Dec 29 12:00:00 PST 2000 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 29Dec00 0) General Status Table History ------------- Date Prefixes 221200 96064 231200 96185 241200 96234 251200 96104 261200 95929 271200 96096 281200 96103 291200 96164 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: 8416 Number of ASes announcing only one prefix: 4902 (2470 cidr, 2432 classful) Largest number of cidr routes: 1112 announced by AS705 Largest number of classful routes: 1652 announced by AS1221 1) Gains by aggregating at the origin AS level --- 29Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1652 1215 437 26.5% TELSTRA-AS AS701 1581 1426 155 9.8% Alternet AS271 284 131 153 53.9% BCnet Backbone AS7545 189 67 122 64.6% TPG Internet Pty Ltd AS9269 165 46 119 72.1% Hong Kong CTI AS8013 449 344 105 23.4% PSINET-CA AS6595 162 63 99 61.1% DODDSEUR AS7657 253 164 89 35.2% The Internet Group Limited AS2563 127 40 87 68.5% KoRean Education Network AS705 326 241 85 26.1% ALTERNET-AS AS4755 209 124 85 40.7% Videsh Sanchar Nigam Ltd. India AS4293 341 258 83 24.3% Internal ASN for C&W AS174 527 448 79 15.0% Performance Systems International AS7496 100 22 78 78.0% Power Up AS4151 278 201 77 27.7% USDA Internet Access Network AS1727 187 111 76 40.6% MRMS-WEST AS7046 329 254 75 22.8% UUNET-CUSTOMER AS724 244 172 72 29.5% DLA-ASNBLOCK-AS AS3908 233 161 72 30.9% Supernet, Inc. AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS13999 79 7 72 91.1% UNKNOWN AS577 240 170 70 29.2% Bell Backbone AS7018 594 527 67 11.3% AT&T WorldNet Service Backbone AS5106 101 37 64 63.4% AADS-COLUMBUS AS3749 122 58 64 52.5% TECNET AS3602 307 244 63 20.5% Sprint Canada Inc. AS226 167 104 63 37.7% USC/Information Sciences Institut AS2548 365 308 57 15.6% DIGEX-AS AS16758 63 6 57 90.5% UNKNOWN AS376 133 77 56 42.1% RISQ 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: RFC1918 addresses to permit in for VPN?
by Danny McPherson 29 Dec '00

29 Dec '00

> This is one of the benchmarks of cluelessness. The other is that the > addresses don't have reverse DNS. Perhaps they do resolve interally to BT, it's just that your resolver can't get anything useful via the normal channels: danny@sofos% dig @a.root-servers.net 16.172.in-addr.arpa ns ; <<>> DiG 8.2 <<>> @a.root-servers.net 16.172.in-addr.arpa ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; 16.172.in-addr.arpa, type = NS, class = IN ;; ANSWER SECTION: 16.172.in-addr.arpa. 6D IN NS BLACKHOLE.ISI.EDU. 16.172.in-addr.arpa. 6D IN NS BLACKHOLE.EP.NET. ;; Total query time: 108 msec ;; FROM: sofos.tcb.net to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Fri Dec 29 11:42:12 2000 ;; MSG SIZE sent: 37 rcvd: 98 Though I agree that using reserved address space in this manner is [usually] a bad idea, I think we [NANOG] have been through this dicussion more than a few times in this past. -danny

1 0

Find Out the TRUTH About AnyOne !!
by Edetect＠mail.cz 29 Dec '00

29 Dec '00

1 0