- NANOG - lists.nanog.org

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

Re: Cisco - ip verify unicast reverse-path
by Paul Ferguson 15 Feb '00

15 Feb '00

At 04:41 PM 02/14/2000 -0800, Alberto U. Begliomini wrote: >If I limit the SYN traffic to 8kbs to host 10.0.0.1 like in the example, I >have >a DoS right there. Let's say the host I am CAR SYN is a web server instead, >then an attacker just need to send 8kps of SYN traffic to prevent any useful >access to my web server. Or am I missing something here? The important thing to take away from this example is that you have a tool to rate-limit traffic. How you set the thresholds is an exercise for the reader. :-) - paul

1 0

Nanog musical video tribute
by Rodney Joffe 14 Feb '00

14 Feb '00

So has anyone found out where/when/if the Merit musical fron San Jose can be obtained/snarfed/downloaded? -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"

1 0

DoS Attack Tracking Tool?
by Tom 14 Feb '00

14 Feb '00

Hello All, I just read this release and was wondering if it was a load or if it has some merit? http://www2.ncsu.edu/ncsu/univ_relations/news_services/press_releases/00_02/ 33.htm The original attack command doesn't necessarily go to the sites being attacked so I am not seeing how this tool would be implemented. I guess it's just to find out what sites are being used to attack you. Cheers, Tom -------------------------------------------- T h o m a s K e i t e l t o m @ b o n z i . c o m ( n e t w o r k a d m i n i s t r a t o r ) -------------------------------------------- L i v e f r e e o r d i e

1 0

RE: Cisco - ip verify unicast reverse-path
by Paul Ferguson 14 Feb '00

14 Feb '00

At 09:58 AM 02/14/2000 -0800, Owen DeLong wrote: > Does ip verify unicast reverse path accept packets for which > the inbound interface is not the preferred outbound interface, but > is a valid outbound interface? This feature looks up the source address in FIB, and if the source address is reachable via the source interface, the packet is forwarded. If it is not, it is punted. Yes, it can occasionally pose problems in situations where the FIB associates the forwarding path for a particular prefix to an interface which is not the one on which the packet was received. This feature is not a panacea, just another tool. - paul

1 0

ARIN Database
by Richard Jimmerson 14 Feb '00

14 Feb '00

Over the last week, an individual faked mail headers and successfully changed the email addresses on the POC records associated with a handful of Class A records in ARIN's database. After successfully modifying the POC records, he modified the inverse mapping servers listed on those Class A network records. Once identified, corrections were made to the records in question. We have spoken with the individual who appeared to have made the unauthorized changes, however, he claims to have been hacked himself and is not responsible for submitting the bogus modification requests. He said his mailboxes looked fake and utmp entries had been tampered with on his machine. Prior to this incident, the ARIN engineering staff had been looking into adding security mechanisms to our database. We would like to invite the community to discuss possible security mechanisms that may be implemented using the following mailing list: Database Implementation Working Group dbwg(a)arin.net To join this mailing list, visit http://www.arin.net/members/mailing.htm This mailing list is open to the public. Regards, American Registry for Internet Numbers (ARIN)

2 1