May 2002 - Test - lists.nanog.org

Re: Re[2]: "portscans" (was Re: Arbor Networks DoS defense product)
by JC Dill 19 May '02

19 May '02

On 07:50 AM 5/19/02, Ralph Doncaster wrote: > >> RD> I often like to know if a particular web server is running Unix or >> RD> Winblows. A port scanner is a useful tool in making that determination. >> >> [allan@ns1 phpdig]$ telnet www.istop.com 80 >> Trying 216.187.106.194... >> Connected to dci.doncaster.on.ca (216.187.106.194). >> Escape character is '^]'. >> HEAD / HTTP/1.0 >> >> HTTP/1.1 200 OK >> Date: Sun, 19 May 2002 01:47:57 GMT >> Server: Apache/1.3.22 (Unix) FrontPage/4.0.4.3 PHP/4.1.2 mod_fastcgi/2.2.8 > >Sure, it works on some servers, but try it on yahoo.com, cnn.com, ... <http://uptime.netcraft.com/up/graph/?mode_u=off&mode_w=on&site=www.cnn.com> Works for me, works from any system that has a browser. At any given time I'm *far* more likely to have a browser running than port scanning software, so this solution is also IMHO faster. jc

2 1

Network Physics
by Timothy Brown 19 May '02

19 May '02

Does anyone on the list have experience with Network Physics? Their product looks pretty good on paper, but I have to admit i'm a little skeptical about products in this class. Does anyone have some insight or some experience with the product, good or bad? Please send replies privately. If there's enough interest, i'll summarize. Thanks, Tim

1 0

Re: "portscans" (was Re: Arbor Networks DoS defense product)
by Johnny Eriksson 19 May '02

19 May '02

Ralph Doncaster <ralph(a)istop.com> writes: > I often like to know if a particular web server is running Unix or > Winblows. A port scanner is a useful tool in making that determination. > > <sarcasm> > And why, pray tell, would some stranger be carrying a concealed gun if > they were not planning on shooting someone? > </sarcasm> Maybe there is a difference between carrying a concealed portscanner and actually using one? --Johnny

1 0

You are invited to participate
by Sean Donelan 18 May '02

18 May '02

In 1999 the President's National Security Telecommunications Advisory Committee (NSTAC) published a report which concluded: "In summary, end-to-end NS/EP services cannot currently be offered via the public Internet. A number of factors (e.g., lack of NS/EP demand, market factors, and lack of regulatory mandates) make it unlikely that the same type of NS/EP services available in the PSN will be available over the Internet for the foreseeable future." Well, its now 2002 and things have changed. Both the FCC Network Reliablity and Interoperability Council (NRIC) and the NCS National Security Telecommunication Advisory Committee (NSTAC) are inviting ISPs to participate in their activities. Since they are busy writing reports about the Internet it might be nice to actually have some people with an Internet perspective. Did you know the next generation Internet will have a MPLS core? http://www.ncs.gov/nstac/nstac.htm FOR MORE INFORMATION ON NSTAC call (703) 607-6209 http://www.nric.org/ NRIC VI Contact PAMELA J. STEGORA AXBERG CHAIR, NRIC VI STEERING COMMITTEE OFFICE: 763-531-6000 FAX: 763-536-5041 CELL: 612-816-7767 EMAIL: pstegor(a)qwest.com 9700 SCHMIDT LAKE ROAD, ROOM 300 PLYMOUTH, MN 55442

1 0

Fwd: RE: Network Reliability Engineering
by blitz 18 May '02

18 May '02

>AHH, MTBF date from vendors....well, there goes the idea of THAT project. >You'll find that data, IF you can find it, will be calculated by sales >cretins, not engineers. >Check out this book: > > "High-Availability Network Fundamentals" > Cisco Press > ISBN 1-58713-017-3 > >Despite its Cisco Press origin, the book is 99% vendor-neutral and applies >to any equipment. It helps you calculate MTBF-based availability of entire >network paths, factoring in various types of redundancy. You're on your own >collecting actual MTBF data from vendors, but this book may help you put it >together into something sensible.

1 0

RE: Network Reliability Engineering
by Jason Young 18 May '02

18 May '02

Check out this book: "High-Availability Network Fundamentals" Cisco Press ISBN 1-58713-017-3 Despite its Cisco Press origin, the book is 99% vendor-neutral and applies to any equipment. It helps you calculate MTBF-based availability of entire network paths, factoring in various types of redundancy. You're on your own collecting actual MTBF data from vendors, but this book may help you put it together into something sensible. > -----Original Message----- > From: Pete Kruckenberg [mailto:pete@kruckenberg.com] > Sent: Saturday, May 18, 2002 6:13 PM > To: nanog(a)merit.edu > Subject: Network Reliability Engineering > > > > I'm looking for some good reference materials to do some > "reliability engineering" calculations and projections. > > This is to justify increased redundancy, and I want to > include quantifiable numbers based on MTBF data and other > reliability factors, kind of a scientific justification > instead of just the typical emotional appeal using analyst/vendor FUD. > > I'd appreciate references on how to do this in a network > environment (what data to collect, how to collect it, how to > analyze, etc). Also any data (or rules of thumb) on typical > MTBFs for network events that I won't find on vendor product > slicks (like what's the MTBF on IOS, or human-caused service > outages of various types, etc). > > If someone has put together something remotely like this > that they'd care to share, that'd be incredibly helpful. > > Thanks. > Pete. > >

1 0

Network Reliability Engineering
by Pete Kruckenberg 18 May '02

18 May '02

I'm looking for some good reference materials to do some "reliability engineering" calculations and projections. This is to justify increased redundancy, and I want to include quantifiable numbers based on MTBF data and other reliability factors, kind of a scientific justification instead of just the typical emotional appeal using analyst/vendor FUD. I'd appreciate references on how to do this in a network environment (what data to collect, how to collect it, how to analyze, etc). Also any data (or rules of thumb) on typical MTBFs for network events that I won't find on vendor product slicks (like what's the MTBF on IOS, or human-caused service outages of various types, etc). If someone has put together something remotely like this that they'd care to share, that'd be incredibly helpful. Thanks. Pete.

2 1

Re: "portscans" (was Re: Arbor Networks DoS defense product)
by Scott Francis 18 May '02

18 May '02

On Sat, May 18, 2002 at 04:10:53AM +0000, dr(a)kyx.net said: [snipage throughout] > > up your network, or risk being blackholed." If no response is received, and > > scans continue, blackhole. Simple as that, and puts responsibility back on > > the shoulders of the offending network. > > Oh but there _WILL_ be disputes. Even with spam there is considerable enough > gray area that I find solutions like the RBL distasteful, and the questions > surrounding what is and isn't a portscan will be much, much, worse. The > simple fact is that there are no good definitions of a portscan. I say this > because I work on developing IDSes and portscan detectors amongst other > things. there doesn't have to be a good definition. If network B receives what they consider to be a scan from network A, and network A does not reply to emails requesting explanation, network B can blackhole. Heck, network B can blackhole whoever they want for any or no reason. It's _their_ network. An agreed-upon definition of what constitutes a portscan is not required, by any means. > Port agile trojan scans won't be caught by any of your "portscan" detectors. > Your "portscan" detection will likely only catch admins who have misfired with > nmap, or kids playing, or legitimate network applications that have high In which case, a simple email to the network operator in question should clear up the confusion early in the game, with no harm done. If people can't be bothered to properly manage their contact information for netblocks, that's nobody's fault but their own. > Bitching about portscans is misdirected and stupid, while lacking a good > definition again, definition is not necessary. I think many network operators are simply tired of dealing with crap from other networks and operators that can't be bothered to clean things up. Consider it fair warning. As long as network operators are responsible for their networks, they can do as they please, including denying contact from arbitrary other networks for any or no reason. > of what a "portscan" is (with all deference to the popularity of nmap :-). > If you think you have some information there you do not want to leak, put in > measures to stop this, but route blocking based on contravention of some > dubious "portscan" regulation is like trying to swat flies with atomic bombs, > you may get the fly, but arguably the cure is worse than the disease. Maybe so, but that decision still belongs to the individual network operators. > > There's no point to what you have just said. When you find a machine has > > been rooted, unplug it from the network and commence forensic analysis. > > Knowingly allowing it to attack other networks is foolhardy at best. > > There we agree to disagree. Blindly shutting down attackers without any ID or > attempt to discern motive seems unwise. But your policies may differ. :-) This is what forensic analysis is for. You cut off the machine and then analyze it. Motive is generally pretty obvious - Yet Another Zombie for use in DDoS, an IRC shell, or a jumping point for further network penetrations. *yawn* The motives are mind-numbingly common at this point. If proper logging is in place, you won't lose any information by unplugging the machine as opposed to allowing the intruders to continue to do whatever they're doing. > I work with several groups that attempt to study intrusions and intruder > techniques. If the villains have broached your defenses and you simply > patch up the defenses with the same construct that was broached initially, > blindly hoping they'll go away... well... further more, if you don't > even look at the villains to identify their motive, strength and number, > simply pretending they aren't there... then you aren't being a good > defender. Forensic analysis after an intrusion does not require continuing to allow the intruders to do as they please. For honeypots, of course, this is a different matter. > Their loss if true. I pity the fool that cannot laugh. Just because I have a sense of humor, does not mean I find it amusing when people penetrate, or attempt to penetrate, my network. > > Neither are network operators whose networks are constantly under attack. > > This kind of thing loses its novelty the first time one of your machines is > > rooted and has to be wiped and rebuilt. > > > > Whether or not it's amusing to you is immaterial. If the person being > > scanned does not find it so, scans should cease, period. > > By all means if you are under attack, filter and protect yourself. > > However a "portscan" is not an attack. Precursor to an attack, certainly. As you mentioned earlier, forewarned is forearmed. If I find myself being scanned, as a responsible network operator I will contact the operator of the block in question, and if things are not cleared up to my satisfaction, I will take proactive measures to protect myself from the attacks that are sure to come by whatever means seem appropriate and necessary to me. regards, -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

2 1

Multicast at broadcast exchanges
by Stephen Griffin 18 May '02

18 May '02

Hmm, I was thinking about the topic of multicast at broadcast exchanges, and had a weird thought. Presently, the various participants may have divergent peering relationships and routing preferences. Such that RPF choices for the same (s,g) can go back to different places. If I remember correctly, all PIM routers on the same broadcast domain will elect a designated router, to keep from sending the same traffic for the same group multiple times. If network A is preferring network B (via localpref, for example) and network C is preferring network D, such that A rpf's to B for prefix E and C rpf's to D for prefix E, how would this be resolved? What if A doesn't peer with D at all, and C doesn't peer with B? Wouldn't one of B and D send the traffic, such that the other isn't sending any, regardless of the policies of any of the networks involved? What if the elected DR isn't one of B or D? The only "workaround" I could see, would be if the multicast traffic were unicasted across the exchange (much like how things are at the atm peering points). However, this nulls out the benefit of having a multicast broadcast exchange.

3 2

The Cidr Report
by CIDR Report 18 May '02

18 May '02

This is an auto-generated mail on Fri May 17 23:00:00 PDT 2002 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 17May02 0) General Status Table History ------------- Date Prefixes 100402 108550 110402 108701 120502 109917 130502 109712 140502 109853 150502 109940 160502 109828 170502 109785 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 10.1.1.1/32 from AS(65302) *** Bogus 10.1.1.1/32 from AS(65303) AS Summary ---------- 1) Gains by aggregating at the origin AS level --- 17May02 --- 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