- Test - lists.nanog.org

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

Re: Now this upsets me, irregardless of the reason
by Sean Donelan 15 Feb '00

15 Feb '00

On Mon, 14 February 2000, "Henry R. Linneweh" wrote: > http://www.techserver.com/noframes/story/0,2294,500168253-500214982-5010085… > > Banks warned of impending Web attacks days before they occurred They have been a number of warnings issued by a several different groups in the weeks, months before the most recent wave received wide press attention. From the article, the banks didn't seem to have much better information than most of the other groups who were tracking things. CERT/CC and NIPC issued warnings, and at least three providers were already pro-actively scanning their networks looking for the signature of compromised hosts. Heck, if you review the NANOG archives, you might even find a message from me which could be read as a warning Yahoo! would be attacked on GlobalCenter's network. Did I have any "inside" information, no. But I do know about the weaknesses of the Internet, and what is likely to attract a lot of public attention and media coverage. But doing a threat analysis is very different from having specific information about a future attack.

1 0

Re: What would you tell the White House?
by Sean Donelan 15 Feb '00

15 Feb '00

On Sun, 13 February 2000, Randy Bush wrote: > > 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. > > and everyone i know, including we, are sending junior note-takers. Don't like being used as a photo-op backdrop while the politicos say the solution is pass my budget request?

1 0

Re: Last Call: Security Expectations for Internet Service Providers to Informational
by Sean Donelan 15 Feb '00

15 Feb '00

On Mon, 14 February 2000, The IESG wrote: > The IESG has received a request from the G and R for Security Incident > Processing Working Group to consider Security Expectations for Internet > Service Providers <draft-ietf-grip-isp-expectations-03.txt> as an > Informational RFC. Several good ideas all providers should implement whether the cause of a service disruption is due to malicious activity or accidents.

1 0

It could've been worse (was Re: DoS (Denial of Service) Attack resource page)
by Sean Donelan 15 Feb '00

15 Feb '00

On Mon, 14 February 2000, Randy Bush wrote: > ettore bugatti, maker of the finest cars of his day, was once asked why his > cars had less than perfect brakes. he replied something like, "any fool can > make a car stop. it takes a genius to make a car go." The scary thing is this was really only a moderate attack. Network engineers created worse Internet disruptions by accident in the past. The difference is intent, not result. The good news is you can use the same techniques to protect against many different causes of service disruptions. Does it matter whether you get hammered by the slashdot effect, or a denial of service attack; a F5 tornado or a ryder truck; a backhoe or a gopher; or the scariest of them all, a Bell technician? I know some people joked when I suggested QoS might be a way to look at DoS, because attackers wouldn't set the low priority bit on their packets. But one way to protect against the slashdot effect or a DoS would be for a host to advertise how much available bandwidth they have, and when it is exceeded start "call gapping" (if I might borrow that term) at the edges. If Yahoo! couldn't handle 1Gigabit(byte) of traffic, their enginers could set their QoS/RSVP/RED with their providers to how much traffic they can handled. This might allow excess traffic to get dropped sooner on a more distributed basis, hopefully preventing single routers or hosts from getting overwhelmed and falling over. Since I've haven't thought QoS was good for anything in the past, maybe this could be the problem the QoS people have been looking to solve. >From what I've heard, the way most providers combatted the current attacks was installing filters and rate-limits on identifiable traffic. The protection depends on the attacker using packets which aren't necessary for the normal functioning of the site.

1 0

Fwd: [cfgeeks] HACKERS LEAVE A TRAIL OF CHAOS, BUT FEW CLUES
by Shawn McMahon 15 Feb '00

15 Feb '00

In light of some recent discussion, I thought I'd forward this quote, from the LA Times: >HARD TIME AWAITS HACKERS GUILTY OF WEB ATTACKS >Whether it's a group of international terrorists or a 16-year-old whose >prank has gotten way out of hand, whoever is behind this week's series >of >"denial of service" assaults on popular Web sites could face serious >penalties. If the damage is intentional, penalties range from six months >to >five years in prison, plus a fine of up to $250,000 for the first >offense, >and up to 10 years in prison for the second offense. Unintentional >damage >caused by negligence is punishable by up to a year in prison and a >$100,000 >fine. The U.S. penalties apply even to foreigners if a U.S. computer is >used >in the attack. (Los Angeles Times 9 Feb 2000) >http://www.latimes.com/business/cutting/techwr/20000209/tCB00V0261.html I'd like to call special attention to that last sentence. For those folks who were telling me I was "off base", "not thinking globally", "being an ugly American", or similar horseshit during this discussion, see here that I am not alone in thinking that somebody is very likely to be dragged into US custody yet again over this.

5 5

DoS (Denial of Service) Attack resource page
by Paul Ferguson 15 Feb '00

15 Feb '00

Folks, Dan Senie and I got tired of keeping separate browser bookmarks on a myriad of DoS Attack technical info, and so we decided to slap together a web page which contains some "good technical resources" on these DoS attacks: http://www.denialinfo.com/ Of course, it is pretty raw right now, but we'll make it easier on the eyes over time, as well as add more content. In fact, I think the page counter on the main page is broken right now, but works on the mirror. Minor problems (it's the content that counts, right?). In any event, this is where you come in -- we would like to solicit the community at-large to send along pertinent pointers to any additional resources which we may have overlooked, or that we just didn't know about in the first place. Contact info is available on the web page, and so is a URL for a mirror. Thanks, - paul and dan ps. Thanks much to Kevin Siers, political cartoonist at the Charlotte Observer, for letting use his awesome cartoon. ;-)

3 2

Fwd: Last Call: Security Expectations for Internet Service Providers to Informational
by Paul Ferguson 15 Feb '00

15 Feb '00

Given the discussion here on the list, it is worth mentioning that this draft has just gone to last call in the IETF. FYI, - paul >To: IETF-Announce:; >Cc: grip-wg(a)uu.net >From: The IESG <iesg-secretary(a)ietf.org> >SUBJECT: Last Call: Security Expectations for Internet Service > Providers to Informational >Reply-to: iesg(a)ietf.org >Date: Mon, 14 Feb 2000 15:44:14 -0500 >Sender: scoya(a)cnri.reston.va.us >X-SPAM: Yes >X-SPAM-REASON: Suspicious TO Address >X-SMTP-HELO: loki.ietf.org >X-SMTP-MAIL-FROM: ietf-123-owner(a)loki.ietf.org >X-SMAP-Received-From: outside >X-SMTP-PEER-INFO: loki.ietf.org [132.151.1.177] > > >The IESG has received a request from the G and R for Security Incident >Processing Working Group to consider Security Expectations for Internet >Service Providers <draft-ietf-grip-isp-expectations-03.txt> as an >Informational RFC. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg(a)ietf.org or ietf(a)ietf.org mailing lists by February 28, 2000. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-grip-isp-expectations-03.txt >

1 0