April 2001 - Test - lists.nanog.org

RE: Information from an FTP violation this weekend.
by Jade E. Deane 23 Apr '01

23 Apr '01

Hello, my toaster is connected at 192.168.5.44 and it was hax0red. My social security number is 275-53-4678, and my favorite color is blue. How pointless is this mail-list? /paxil > On Mon, 23 Apr 2001, Smith, Rick wrote: > > > > > > > Nanog; fyi. > > > > APNIC / Excite / Home.net - > > > > We have an ftp site running on 209.123.52.40 that is made writable at > > certain periods of time for anonymous users. Some of our customer's systems > > are programmed to send in bug reports, problem programs, etc at these times. > > One of these periods of time was this past Friday (4/20/01) from 6pm EST to > > Saturday afternoon at Noon. In that time period, a couple of hundred megs > > of movies / warez / crap was dropped onto the ftp site, and then the people > > that were (I presume) loading up the site got cut off. > > > > Not only did the violator from 203.164.51.0/24 store illegal information on > > our ftp site, they also deleted everything that existed. Not anyone's fault > > there but our own, and no problem since there were backups, but just fyi > > that this stuff is happening out there from the reported networks. > > > > Here's some information I collected from a .htaccess file in one of the > > directories that these <insert explative here> left. > > > > <Limit GET> > > order allow,deny > > deny from 141.201.222. > > deny from 24.141.20. > > deny from 24.141.36. > > deny from 65.1.50. > > . > > . Bunch of Denies > > . > > allow from 203.164.51. > > deny from 203.164.3. > > deny from 62.30.0. > > . > > . Bunch of Denies > > . > > allow from all > > </Limit> > > > > > > > > I run Portsentry on my FreeBSD firewall, which caught and denied this: > > 987814775 - 04/20/2001 20:59:35 Host: www.uov.net/209.37.153.6 Port: 515 TCP > > Blocked > > > > > > The swip info for the one allow statement in that htaccess file: > > > > [root]# whois -h whois.arin.net 203.164.51.0 > > > > Asia Pacific Network Information Center (APNIC2) > > These addresses have been further assigned to Asia-Pacific users. > > Contact info can be found in the APNIC database, > > at WHOIS.APNIC.NET or http://www.apnic.net/ > > Please do not send spam complaints to APNIC. > > AU > > > > Netname: APNIC-CIDR-BLK > > Netblock: 202.0.0.0 - 203.255.255.255 > > Maintainer: AP > > > > > > Gee - go figure - a cable modem ween > > > > [root]# whois -h whois.apnic.net 203.164.51.0 > > > > % Rights restricted by copyright. See > > http://www.apnic.net/db/dbcopyright.html > > > > inetnum: 203.164.48.0 - 203.164.51.255 > > netname: ATHOME-AU-RIVRW-1 > > descr: Infrastructure > > country: AU > > admin-c: HH85-AP > > tech-c: AI13-AP > > mnt-by: MAINT-AU-ATHOME > > changed: ipmgmt(a)excitehome.net 20000911 > > source: APNIC > > > > person: Hostmaster Home Network Australia > > address: 100 Harris Street > > address: Pyrmont > > address: NSW 2009 > > phone: +61 2 9005 1000 > > fax-no: +61 2 9005 1076 > > country: AU > > e-mail: hostmaster(a)homenetwork.com.au > > nic-hdl: HH85-AP > > mnt-by: MAINT-AU-ATHOME > > changed: judithh(a)corp.home.net 20000830 > > source: APNIC > > > > person: ATHome-AU IP Mgmt > > address: 450 Broadway Street > > address: Redwood City, CA 94063 > > address: US > > phone: +1-800-872-3595 > > country: AU > > e-mail: ipmgmt(a)excitehome.neet > > nic-hdl: AI13-AP > > mnt-by: MAINT-AU-ATHOME > > changed: judithh(a)corp.home.net 20000830 > > source: APNIC > > > > > > > > Thanks, > > Rick Smith > > Director of Technical Services > > Applied Tactical Systems > > (A division of Vertex Interactive, Inc.) > > <http://www.atsworld.com> --- <http://www.vertexinteractive.com> > > (973) 808 - 1750 x382 > > > > > > > > -- > Stephen J. Wilcox > IP Services Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > >

1 0

Future of route-servers
by Vinny India 23 Apr '01

23 Apr '01

Anyone out there know what the future is for route servers at MAE-EAST, I don't know of any route-servers being implemented off the MAE-ATM service. If anyone knows something please let us know.

2 1

Information from an FTP violation this weekend.
by Smith, Rick 23 Apr '01

23 Apr '01

Nanog; fyi. APNIC / Excite / Home.net - We have an ftp site running on 209.123.52.40 that is made writable at certain periods of time for anonymous users. Some of our customer's systems are programmed to send in bug reports, problem programs, etc at these times. One of these periods of time was this past Friday (4/20/01) from 6pm EST to Saturday afternoon at Noon. In that time period, a couple of hundred megs of movies / warez / crap was dropped onto the ftp site, and then the people that were (I presume) loading up the site got cut off. Not only did the violator from 203.164.51.0/24 store illegal information on our ftp site, they also deleted everything that existed. Not anyone's fault there but our own, and no problem since there were backups, but just fyi that this stuff is happening out there from the reported networks. Here's some information I collected from a .htaccess file in one of the directories that these <insert explative here> left. <Limit GET> order allow,deny deny from 141.201.222. deny from 24.141.20. deny from 24.141.36. deny from 65.1.50. . . Bunch of Denies . allow from 203.164.51. deny from 203.164.3. deny from 62.30.0. . . Bunch of Denies . allow from all </Limit> I run Portsentry on my FreeBSD firewall, which caught and denied this: 987814775 - 04/20/2001 20:59:35 Host: www.uov.net/209.37.153.6 Port: 515 TCP Blocked The swip info for the one allow statement in that htaccess file: [root]# whois -h whois.arin.net 203.164.51.0 Asia Pacific Network Information Center (APNIC2) These addresses have been further assigned to Asia-Pacific users. Contact info can be found in the APNIC database, at WHOIS.APNIC.NET or http://www.apnic.net/ Please do not send spam complaints to APNIC. AU Netname: APNIC-CIDR-BLK Netblock: 202.0.0.0 - 203.255.255.255 Maintainer: AP Gee - go figure - a cable modem ween [root]# whois -h whois.apnic.net 203.164.51.0 % Rights restricted by copyright. See http://www.apnic.net/db/dbcopyright.html inetnum: 203.164.48.0 - 203.164.51.255 netname: ATHOME-AU-RIVRW-1 descr: Infrastructure country: AU admin-c: HH85-AP tech-c: AI13-AP mnt-by: MAINT-AU-ATHOME changed: ipmgmt(a)excitehome.net 20000911 source: APNIC person: Hostmaster Home Network Australia address: 100 Harris Street address: Pyrmont address: NSW 2009 phone: +61 2 9005 1000 fax-no: +61 2 9005 1076 country: AU e-mail: hostmaster(a)homenetwork.com.au nic-hdl: HH85-AP mnt-by: MAINT-AU-ATHOME changed: judithh(a)corp.home.net 20000830 source: APNIC person: ATHome-AU IP Mgmt address: 450 Broadway Street address: Redwood City, CA 94063 address: US phone: +1-800-872-3595 country: AU e-mail: ipmgmt(a)excitehome.neet nic-hdl: AI13-AP mnt-by: MAINT-AU-ATHOME changed: judithh(a)corp.home.net 20000830 source: APNIC Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

2 1

Cooler servers for the Internet
by Sean Donelan 23 Apr '01

23 Apr '01

IBM is announcing several new servers today. One interesting feature of the press release is a new focus on power consumption and cooling. IBM directly targets the high heat generated by the SUN servers. Compared to a Sun Server, the new IBM servers have 1/3 the heat dissipation, based on the published specifications. IBM eServer p660 is 3,294 BTUs/hr compared with 9,420 BTUs/hr for a Sun Fire 3800. Of course, these numbers are pretty bogus. Most computer manufacture specification sheets are useless for accurately forecasting the power consumption of the equipment. I suspect, after Sun's PR people realize they are getting beat up, they will go back and better calculate the power consumption figures for their servers. I'm not very interested in who really has the coolest, most efficient computers. I am interested in getting accurate information for planning purposes. If this leads to computer vendors publishing more accurate information, great. I'm afraid instead, the pendulum will swing the other direction and vendors will begin understating their true power requirements.

5 5

bgpd.pl, a BGP daemon written in perl
by Steven Hessing 23 Apr '01

23 Apr '01

A first release of bgpd.pl, a limited functionality BGP daemon written in perl is now available. This software is alpha stage. Further testing is required for: - interoperability testing with other BGP software (currently Zebra and Cisco have been tested) - testing with multiple concurrent BGP connections plus local-RIB route selection This software is not intended to be used for packet forwarding purposes, indeed functionality is missing to fullfil this role. This tool can be useful for real-time monitoring of BGP routing tables. The software can easily be extended to implement specific monitoring functions since it has been written in perl and its datatypes are well documented. Which monitoring functions could be useful I leave up to your imagination. I have attached the README of the package to the end of this mail. The software can be downloaded from: http://www.fasttracknetworks.com/software/bgpd.pl/ Bug reports are appreciated and if someone is willing to set up a eBGP connection to me then I could test the route selection code. - Steven Hessing README: bgpd.pl Version 0.01 (C)2001 Steven Hessing steven(a)xs4all.nl bgpd.pl is a partial implementation of the BGP protocol (RFC1771) in perl. It was written as a tool to monitor BGP routing updates. It is NOT written to be used as a BGP router in an operational network, in fact is has no support to propogate routing information because there is no code to send BGP UPDATE messages. bgpd.pl also does not touch the routing table of the host it runs on. With the constraints described in the above text, the software supports the following RFCs to the extend indicated: RFC1771 - Border Gateway Protocol version 4 adj-RIB-out not maintained, no outgoing BGP UPDATE messages, BGP TCP sessions are not initiated. No Finite State Machine support. RFC1863 - BGP Route Server Route Server client behaviour is supported. bgpd.pl can't act as a route server RFC1997 - BGP Communities attribute supported RFC2385 - Protection of BGP Sessions via the TCP MD5 Signature Option not supported RFC2439 - BGP Route Flap Damping not supported, not needed because we don't send out UPDATES RFC2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing not supported RFC2547 - BGP/MPLS VPNs not supported RFC2796 - BGP Route reflection supported RFC2842 - Capabilities Advertisement with BGP-4 We don't follow this RFC when a neighbour doesn't support a capability that we do. We keep announcing the same set of capabilities. RFC2858 - Multiprotocol Extensions for BGP-4 almost no support. We recognise the RFC2842-capability announcement RFC2918 - Route refresh capability for BGP-4 supported RFC3065 - Autonomous System Confederations for BGP supported The following RFC drafts are not yet supported: draft-ietf-id-bgp4-12 draft-ietf-id-route-filter-03 draft-ietf-id-restart-00 draft-ietf-id-as4bytes-01 draft-ietf-id-route-oscillation-00 Multiprotocol support: Although the MP capability is accepted and announced in the BGP OPEN message, all MP path attributes in BGP UPDATE messages are silently ignored. There is no support for the MPLS/BGP VPN application or IPv6. This is planned for future releases. DOWNLOAD: The home page of bgpd.pl is: http://www.fasttracknetworks.com/software/bgpd.pl/index.html INSTALLATION: - download and install Net::Patricia from http://net.doit.wisc.edu/~plonka/Net-Patricia/ - cd <parent-dir>; tar zxvf bgpd.pl.tar.gz USAGE: - cd into the bgpd.pl directory - ./bgpd.pl [--log [syslog|file|stdout] ] [ --daemon] [--debug [level] ] [ --as <asnumber> ] - There are many debugging levels, read the `LOGGING' file. If you enable full logging then prepare for a lot of logging information! For a full BGP table you'll get log file of close to 100MB - The default AS is 65100 which is a private AS. - set up a BGP session from your router to the host on which you run bgpd.pl If you use a private AS then don't forget to enable eBGP multihop on your router. If you prefer to use iBGP then I would suggest configuring your router as a route reflector for this BGP connection. - edit the bgpd.pl script to get the kind of monitoring functionality that you need. You'll mostly use the %adjRIBin, %localRIB and %peers hashes. They are described in the file DATATYPES - if you have specified `file' or `stdout' for logging then you can send the bgpd.pl process a kill -1 to get a dump of the routing table. SECURITY CONSIDERATIONS: - connecting this alpha-stage software which has undergone limited testing to your production network can result in considerable damage to your network! Use this software at your own risk! - this software runs as root because it needs to connect to the TCP/BGP port. The code does not switch back to a regular UID yet. It opens a logfile for writing in the current working directory under the name bgpd.log. Make sure that this is not a (sym-) link! INTEROPERABILITY: - bgpd.pl has succesfully maintained BGP sessions with: - Zebra 0.91A - Cisco IOS ios 12.0(14)S2 running on a Cisco 7206 WARNING: There should be no problem running a bgp connection between a router in a production network and bgpd.pl because in no circumstance will bgpd.pl propogate routing information nor will it change the routing table of the host it runs on. BUT, this is alpha code and has undergone limited testing so use it at your own risk. Better connect it to your test network for now.

3 3

More AOL questions -- Have you dealt with them?
by Alan Clegg 23 Apr '01

23 Apr '01

Ok, my request for contact information for AOL postmaster type contacts didn't really go very far, so I'll ask a question that is directly relavent to network managers on this list. Have any of you that run mailing list services had to go through the "white-listing" process with AOL? I'm being asked (forced?) to sign an agreement that lists the things that AOL requires of me (one of which is "do not distribute this list"). Some of the items on the list are OK as far as spam reduction go (and things that I support already), but others are incredible, and just plain WRONG. I'm just wondering if others have been black-mailed into signing this agreement. If you have *NOT* had to sign a legal agreement, what have you done to be allowed to send "high volume" mail into AOL? They continue to drop (silently) e-mail from mailinglists.org, and continue to tell the list managers and clients (their clients and mine) that it is due to mailinglists.org being a source of spam (which it is not). I'm tired of doing my best to do the right thing, and then having my clients told by AOL that my systems are spam sources and that by blocking my traffic, they are helping out with the world's junk mail problem. Thanks, AlanC

1 0

Re: What does 95th %tile mean?
by k claffy 23 Apr '01

23 Apr '01

[at the risk of dampening the whole nanog atmosphere by throwing real operational data in to this thread] nevil wrote a paper 2 years ago on use of 75th percentile ("3rd quartile day") for his academic network http://www.auckland.ac.nz/net/Accounting/3qd-kaw.pdf http://www.otago.ac.nz/ITS/ts/Kawaihikoservices.html (nice work, tho for unrelated political reasons that network happens to not exist anymore so there's not really a source of longterm data since 99 on it but there we are) k

1 0

Re: Chinese hackers plan week-long attack
by Roger Marquis 22 Apr '01

22 Apr '01

Scott Francis <scott(a)virtualis.com> wrote: > it's going to take more than one (or a hundred) data points to counter human > nature (which is competitive, rather than cooperative). I guess I'm just a > little too cynical to believe that the spirit of cooperation is enough to > counter corporate greed, malicious activity and general cluelessness. Cynical is right. This is not so much an issue of good vs. bad, IMHO, but of cost vs. benefit. Whether nationality-based or other hacking is a good thing or a bad thing perhaps depends on your perspective (and defenses). State sponsored information terrorists have to be encouraged by our large number of weakly protected hosts and networks. Poor monitoring, smurfable border routers, NOCs with no authority or ability to implement ad-hoc filtering, sales sites running IIS... On the other hand only a serious attack is going to motivate political and economic interests to protect themselves. The Internet today looks a lot like Europe before WWI with some nations developing tank and rocket offenses (them) while others are complacent with their cavalry-based defenses (us). What defenses do NANOG operators have against well funded extra-national attacks? -- Roger Marquis Roble Systems Consulting http://www.roble.com/

2 1

RE: www.psi.com up, down, ?
by Roeland Meyer 22 Apr '01

22 Apr '01

The server is r e a l s l o w. > -----Original Message----- > From: Sean Donelan [mailto:sean@donelan.com] > Sent: Sunday, April 22, 2001 1:39 AM > To: nanog(a)merit.edu > Subject: www.psi.com up, down, ? > > > > Is www.psi.com down or just extremely slow. I've been trying > to check it since last evening, and can't get response. PSI's > network is up, and mail gets to their NOC address. But www.psi.com > site seems to be out to lunch. > > > > >

1 0

Interpreting trace and ping
by Nguyen, Tran 22 Apr '01

22 Apr '01

Hello, Please point me to some info about interpreting the outputs for the traceroute and ping commands. More specifically with regards to the flags in the Unix commands and Cisco's extended commands. I have read the man pages and scourged cisco's website. In essence, I would like to know how people have used them, i.e., what one would expect to see under certain circumstances. For example, how rate-limit might affect the output, why certain bit patterns are useful in troubleshooting certain links. Basically I would like a more granular understand in the use of the commands other than the usual reachability and path info. Sourcing, packet size, no name-lookup, DF bit , etc, etc, are items everyone is familiar with. Please advise. thanks

1 0