February 2000 - Test - lists.nanog.org

private RFC-1918 addresses on public routers
by William Allen Simpson 18 Feb '00

18 Feb '00

Usually, when a "private" address hits the bogon filters, a quiet note to the perpetrator gets the problem fixed promptly. This time, the fellow seems to want to argue. Since he's been on this list for awhile (posted here about 8 months ago), perhaps he's educable. His characterization isn't what I remember from the previous discussion(s). Moreover, with the recent emphasis on filtering bogus source addresses, maybe it's time to take a stronger stand on the practice. The facts: - a not-insignificant regional public backbone. - a private class B (172.19) on public backbone router interfaces, contrary to the guidelines in RFC-1918 (p 3). - a congested link that generates a significant number of ICMP messages. - the private source address is not being properly filtered by the ISP from reaching the public network, as required (RFC-1918 p 5). - upstream links with non-maintained (missing) in-addr entries. - traceroute downstream, after this private address, on the way to a medium-sized university, disappears into a black hole, although the university itself is certainly not in private address space. While not of earth-shaking consequence, it clearly isn't helpful for debugging the network. What kind of actions should we take? Complain to a supervisor? Construct a web page of infamy? #(name removed to protect the guilty) # I have followed and participated in several of the lively NANOG discussions. # As I recall the usual conclusion on NANOG is - let's agree to disagree. That # seems to me to leave it open to interpretation on whether this practice is # good - it saves public IP space, or bad - you can see it on a traceroute. # # I am aware of the MTU problem but how does it break ICMP? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

5 5

Re: Robustness principle considered harmful
by Forrest W. Christian 18 Feb '00

18 Feb '00

On Fri, 18 Feb 2000, Jon Ribbens wrote: > Not a particularly good rule anyway, if you ask me. (Which you didn't.) > > It should be "be conservative in what you send, and conservative in what > you accept". Actually, my REAL opinion on this (based on several years of process control - which MUST be reliable lest someone get killed) is this: "Be conservative in what you send, and don't be surprised if someone else sends you something you don't expect, and be prepared to deal with it". or, in the process control world: "Be very consistent (safe) in what you do, even when presented with bogus data." I think that was really the intent of the robustness principle. But lest we get in to an argument and reduce the S/N ratio of nanog (if that is possible)... The real point of my message was this: Using RFC1918 space in a net-visible manner is being liberal in what you send and being liberal in what you send is not a good idea. ESPECIALLY when people are being conservative in what they accept. Off-topic note: It seemed like every chuck of process control code I wrote ended up being something like "If it fails this way do this, if it fails this other way, do this, if it fails in yet another bizzare way, do this, and, if by chance it actually worked, do this." 90% of the code was dealing with failure modes. From my experience CGI scripting/network programming tends to be about the same. - Forrest W. Christian (forrestc(a)imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

1 0

What would you tell the White House?
by Sean Donelan 17 Feb '00

17 Feb '00

On Sun, 13 February 2000, Randy Bush wrote: > politicans think engineers will try to apply a clueless and inappropriate > technical solution to non-technical problems. and they're right. True. Nevertheless the White House is having a meeting on Tuesday about last weeks Internet incidents. Several people from this list, and other Internet CEO's have been invited. But not everyone will have a chance to say something. If you had the opportunity, what would you tell the politicans? Try to avoid technical jargon. Imagine someone from the Old Executive Office Building is reading this list and will need to summarize the suggestions. If you say "do nothing," please try to justify your position with something more than the government is clueless. For example, how effective was the private sector response.

12 11

FWD >New Tool for DDoS Defense
by Sehmel, William C. 17 Feb '00

17 Feb '00

Forwarded from Bugtraq <snip> I've written a tool for remotely telling ddos zombies to stop flooding. Most detectors out there will not detect during a flood (due to the traffic involved), so I thought trying to turn the flood off might be kind of nice. Like the detectors, it assumes default settings on the ddos daemons. Works against Trinoo, TFN, and Stacheldraht. Go to http://razor.bindview.com/ and follow the links to Zombie Zapper, unix and NT versions available with source code. - Simple Nomad - No rest for the Wicca'd - - thegnome(a)nmrc.org - www.nmrc.org - - thegnome(a)razor.bindview.com - razor.bindview.com - </snip>

1 0

Re: What would you tell the White House?
by Ron Buchalski 16 Feb '00

16 Feb '00

Sean, A few ideas... The ISPs who are providing services to their customers have a responsibility to implement the measures necessary to prevent or reduce the impact of malicious attacks such as those which have occurred over the past week. In addition, it's the customer's responsibility to make sure that they have the necessary measures to protect their networks and hosts, and that they've verified that their ISPs are protecting them. I don't think that the federal government needs to pass a law defining how one should protect his networks, or how an ISP should implement network protection measures. If the Internet industry developed a set of rules/guidelines (Barry Greene's document, as well as pertinent RFCs such as 2267, are a good starting place), the customers can shop around to find a provider who will protect his network. After all, this isn't a regulated monopoly, like an RBOC. The ISPs need to put a system in place where they can work together to quickly trace and isolate the source of any attack. Perhaps the vendors need to develop some mechanisms to facilitate this. If we had the ability to quickly conduct a cooperative trace of of an attack, and it would result in the apprehension and eventual prosecution of the attackers, it would serve as a good deterrent to future attacks. My $0.02, -rb ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

6 7

Clinton fights hackers, with a hacker
by Henry R. Linneweh 15 Feb '00

15 Feb '00

New story same twist, http://www.cnn.com/2000/TECH/computing/02/15/hacker.security/index.html -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

2 2

GeekTools SuperWhois V3.0 is up...
by Rodney Joffe 15 Feb '00

15 Feb '00

Hello, We've put the latest version (V3.0) of GeekTools SuperWhois up on www.geektools.com. Currently, we've only replaced the web version so that we can debug it easily (with your help) before releasing the *nix source, and the Windows client. Major changes: You can over-ride the default server, and select a specific whois-server to query. It digs down as far as it can automatically. So, for example, with Australian ip addresses, it will query the Telstra database if appropriate. You can add whois server specific parameters (like "host" at NSI). We now dig down into rwhois servers if we know they exist. The only one set up so far is the Exodus one. If you know of any additional *functioning* rwhois servers, please send details to comments(a)centergate.com. We now query some web based cc-tld whois servers where no port 43 machine is available, and parse the data. We ignore those that are so complicated that we can't be sure of the format. Help screens are available. As always, you're restricted to 50 queries a day per ip address, unless you convince us of your need in a friendly email. And finally, we're still open to suggestions for additional services to query through the proxy. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"

1 1

Now this upsets me, irregardless of the reason
by Henry R. Linneweh 15 Feb '00

15 Feb '00

Its nice to know the government just fractured the network and raped everyone's security all to hell... http://www.techserver.com/noframes/story/0,2294,500168253-500214982-5010085… Banks warned of impending Web attacks days before they occurred -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

3 2

!white.house, !panacea, new traceback paper from stefan savage
by k claffy 15 Feb '00

15 Feb '00

(not sure if this has been posted yet, sorry if so) new relevant paper worth checking out by stefan savage et al (david, ann, tom, all UW) disclaimer, these folks just at the "explore the problem" stage and not the "propose a complete implementation now" stage. but exploring the problem is good From Stefan: On Thu, Feb 10, 2000 at 05:14:56PM -0800, Stefan Savage wrote: Hi KC, We've been doing some work on efficient network support for tracing denial-of-service attacks and all of a sudden the topic has some relevance (a strange experience as a researcher ;-). Anyway, this seemed like a good time to introduce our work and try to get some feedback on it. We've put a copy of our paper at: http://www.cs.washington.edu/homes/savage/traceback.html If you have a moment, we'd definitely appreciate any comments you might have. We're also especially interested in getting feedback from the ISP operations community and from equipment vendors, so please feel free to forward this to anyone you think might be interested. Thanks! - Stefan <savage(a)cs.washington.edu>, coauthor david wetherall <djw(a)cs.washington.edu> (and anna and tom) speaking of non-panaceas, brett mentioned caida passive monitoring for security. lemme clarify, coralreef has some bits that can detect port-scanning and then auto-trigger full framed collection on specific filter http://www.caida.org/Tools/CoralReef/ but it's quite different animal from traceback eg., what rstone's centertrack trying to do http://www.nanog.org/mtg-9910/robert.html (not sure where that stands wrt deployment) or what ddrew's cisco-based DOStracker did for what's.now.cw.net brettw also said if we installed passive monitors on IX links between providers, we might be able to do some interesting security traces. reckon you[pl.]'d have to install a lot of them and some facility for correlating among them (and at least coral doesn't have any of that yet, nor any kind of auto-paging when something looks suspicious) again, nothing money & hardware & code & a NOC contact list can't heavily dent in a year or 2 if folks wanted it badly enough. and with other positive benefits to boot. (in case folks think the malice of undersocial teenagers is the biggest threat we face...)

3 2

Fwd: Protocol Action: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing to BCP
by Paul Ferguson 15 Feb '00

15 Feb '00

FYI, - paul >To: IETF-Announce:; >Cc: RFC Editor <rfc-editor(a)isi.edu> >Cc: Internet Architecture Board <iab(a)isi.edu> >From: The IESG <iesg-secretary(a)ietf.org> >Subject: Protocol Action: Network Ingress Filtering: Defeating Denial > of Service Attacks which employ IP Source Address Spoofing to BCP >Date: Tue, 15 Feb 2000 09:23:37 -0500 >Sender: scoya(a)cnri.reston.va.us > > > >The IESG has approved 'Network Ingress Filtering: Defeating Denial of >Service Attacks which employ IP Source Address Spoofing' <rfc2267> as a >Best Current Practice. > >The IESG Contact Persons are Randy Bush and Bert Wijnen. > > >Technical Summary > > This document describes recommended router configurations to reduce > likelihood of attacks over the network. It describes how an ISP customer > aggregation router should be configured to prevent a customer from sending > packets with source addresses from space other than their own. > >Working Group Summary > > This is not the product of a working group, but has been used in practice, > has passed general IETF last call twice, and is generally considered to be > good practice. > >Protocol Quality > > This was reviewed for the IESG by Randy Bush. >

1 0