- NANOG - lists.nanog.org

Re: Proactive steps to prevent DDOS?
by Richard A. Steenbergen 29 Jan '01

29 Jan '01

On Sun, Jan 28, 2001 at 11:45:03AM -0800, Jason Legate wrote: > > > I would add careful use of some rate-limiting > > functionality, > > (already mentioned in Richard Steenbergen's > > http://www.e-gerbil.net/ras/dos.txt) > > so you can rate-limit things like icmp and acks > > numbered 0 and anything > > else that show themselves to be obvious candidates > > over time. > > In actuality, in a TCP SYN packet, an ack of 0 is very > common. If you view legitimate syn's generated by > real stacks, you will see at dword offset 7: > 0x00000000. > > Last time I checked, this was a 0 for all intents and > purposes. By rate-limiting acks of 0, you are > rate-limiting most syn packets, which I don't think is > the ultimate goal. Jason don't be silly, obviously if the SYN bit is set its not an ACK flood. This is just an example of predictable misbehavior which can usually be identified in any kiddie attack (TH_ACK and ack field 0 in the case of stream). But you should know this... :P An attacker can always change their tactics and manage to throw out packets which can slip past a filter ruleset. Rate-limits are only useful for a) protecting the surrounding network not necessarily the target, b) when the traffic you are rate-limiting is desired but not absolutily necessary under attack conditions (ex: icmp echo-replies are valued but during a smurf you can live without them), or c) when you have carefully engineered seperate rate-limit buckets so that an attacker targetting one service may not disturb another. Other steps must be taken in conjunction, and rate-limiting is only one small tool in the arsenal. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Greg, you're tryin' too hard
by Jay R. Ashworth 29 Jan '01

29 Jan '01

[Apologies to NANOG; Greg sent me a reply off list, all three of his addresses feed to weird, and weird is *still* *entirely* too Catholic about machines with perfectly valid A records that do not also have MX records. I won't be continuing this thread, so as to avoid annoying anyone.] I don't know that you'll actually *get* this; ISTR you having your mailer set to be More Catholic Than The Pope... On Sun, Jan 28, 2001 at 02:12:27AM -0500, Greg A. Woods wrote: > [ On Saturday, January 27, 2001 at 21:57:00 ( -0500), Jay R. Ashworth wrote: ] > > Subject: Re: How common is lack of DNS server diversity? > > > > Well, actually, Greg, there are multiple root clusters, with multiple > > sets of authoritative root servers -- but only one of those is > > consecrated by DoC/ICANN. > > Yeah, OK, but the "consecrated" set isn't a "cluster", If I'm guessing > correctly what you mean by that... I meant it in the administrative sense, not the technical one. Yeah, by that definition, it's a cluster. > > The other ones do exist, do work, and so far as I'm aware, there are > > not currently any rogue redelegations of "traditional" gTLDs, nor many, > > if any, collisions of non-traditional gTLDs, amongst the various ones. > > Yeah, but just what percentage of real users ever hit them? I know of > no major ISP that uses anything but the DoC/IANA DNS. Come to think of > it I don't know of *any* ISP using the rogues. No, I don't think they do, at the moment. None of the first or second tier access providers, certainly. I do know of at least a few third-tier (read: mom-n-pop's) that are. > I don't know exactly how the rogues work either, though if I'm guessing > right they're not very safely or securely implemented since they'll > require recursion be enabled. So, "work" might be a relative term here. Indeed. I don't know if they're separating resolver and zone servers or not. They should be, of course; I haven't dug into the technical details. I *can* say, though, that not all the people involved are Friends-of-Gene, nor kooks. > I don't think I've ever seen a published URL point to any of there new > TLDs either, and of course even if I did I couldn't see if it "worked" > anyway. That depends, of course, on your definition of "published". :-) > Nice experiments maybe, pushing the envelope possibly, but otherwise a > total waste of time and effort. I don't think so at all. While who runs the root servers and who runs the root *zone* are two separate questions, unfortunately almost always conflated, in the long run I think that the word 'confederation' will almost have to be the best term for the former... (I absolutely *shudder* at the thought of the FBI pulling a raid on NetSol and yanking *all* their roots down simultaneously... and if you think that can't happen, you ain't been paying attention), and as for the latter...well, we'll see. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015

4 6

Re: Hanging SMTP sessions...
by Avi Freedman 29 Jan '01

29 Jan '01

In article <101029.10550.20206(a)avi.netaxs.com> you wrote: One problem we've seen is with mail servers which want ident, and remote sites which firewall ident - but by silently swallowing the SYNs instead of sending RSTs. FYI, Avi : Hi all, : anyone come across stuff like this? We are runing qmail 1.03, and i'm seeing : some strange things. I have a number of SMTP sessions which just hang, and : then time out. No mail is actually accepted from these sessions... : load is 0.00, so the processes are just hanging around for no reason... : and it's always the same sources...

1 0

Sprint reports fewest number of FCC reportable outages
by Sean Donelan 29 Jan '01

29 Jan '01

Sprint issued a press release today announcing it had the fewest FCC reportable outages in 2000. http://www3.sprint.com/PR/CDA/PR_CDA_Press_Releases_Detail/1,1694,2203,00.h… While my arithmetic doesn't exactly agree with Sprint's, Sprint did do an admirable job delivering service last year. The FCC reporting guidelines tend to impact carriers with LEC operations more than IXC operations, so you can't directly compare carriers on the aggregate numbers. And the thresholds don't show how well a carrier serves an individual customer. I did find the cover letter on the FCC outage report 00-018 interesting. Apparently there was some debate whether "inter-provider congestion" should be considered a reportable outage. I liked the comment that this was the first time this type of impairment has ever occured in Sprint's network. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/20… In the end, the FCC had a more expansive definition of outage, which includes inter-provider congestion.

1 0

Re: Proactive steps to prevent DDOS?
by Steven M. Bellovin 29 Jan '01

29 Jan '01

Some folks may have noticed that I'm already listed on the NANOG program to give a talk on "pushback", a scheme for defending against DDoS attacks. Ratul Mahajan, Vern Paxson, Sall Floyd, Scott Shenker, John Ioannidis, and I have nearly finished writing a paper describing the scheme; we hope to make it available on the Web within the next couple of weeks. A note of caution: this is a research paper; it's not something you can turn on on your router today. I'm discussing it at NANOG because we really want input from operators and vendors on how feasible it seems, and on what we've missed. --Steve Bellovin, http://www.research.att.com/~smb

1 0

Re: [Fwd: Monitoring highly redundant operations]
by Justin W. Newton 29 Jan '01

29 Jan '01

> >>On Wed, 24 Jan 2001, Simon Lockhart wrote: >> >>> >>> Indeed. We currently monitor each part of our operation from a monitoring >>> station on our network. Under certain conditions, this can give us both >>> false positives and false negatives: >>> >>Umm... Keynote? >>(http://www.keynote.com) >> >>I find it truly amazing that people don't already diversely >>monitor. Hell, have cronned pings running off your friend's cable modem >>if that's all you can afford, but for christ's sake, a single box colo'd >>in someone else's cage, or a shell at shells.com or nether.net really >>isn't that expensive. >> >> >>Fighting the war against bad networks, >> >>Matthew Devney >>Teamsphere Interactive > > >Might be interesting to define a set of basic monitoring functions >that independent ISPs can run on each other and share results. Early >warnings could go to a special email. Concillience <http://www.concillience.com> already provides this as a third party service. They have located agents on a variety of networks world wide, and are able to provide both real time alerts, as well as longer term trending information. Their data collection service has the ability to track things like "Network X has low throughput to Network Y.", and similar kinds of issues. Keynote goes part way to a solution to this problem, but, IMHO, doesn't go far enough. -- Justin W. Newton Senior Director, Networking and Telecommunications NetZero, Inc.

1 0

RE: Cat. 6509 - Foundry Server Iron Interoperability
by Alison Gudgeon 29 Jan '01

29 Jan '01

And it works...... set port negotiation [mod/port] disable Thanks to all who replied ;) -----Original Message----- From: Michael Hawk [mailto:hawk@globalcenter.net] Sent: 29 January 2001 18:10 To: Alison Gudgeon Subject: Re: Cat. 6509 - Foundry Server Iron Interoperability Hello, 'port negotiation' - not the same as auto-negotation seen w/ 10/100, but is an option on a GigE port on a cat 6509. Try this: set port negotiation [mod/port] disable ex: set port negotiation 2/3 disable Good luck. -mike On Mon, Jan 29, 2001 at 05:44:40PM -0000, Alison Gudgeon <agudgeon(a)firstnet.co.uk> wrote: > > > Hi All, > > I wonder if anyone else has experienced the following problem and could > perhaps offer a solution: > > Interconnecting Catalyst 6509 Short Haul GBICs up to a Foudry Server Iron SX > with SC-SC fibre patch lead. The foundry sees a link light BUT the cisco > see's nothing connected. What sprung to mind was auto neg. problems on the > CAT but auto neg is not a supported option so it can't be this? > > > > Thanks in advance. > > > Alison > > >

1 0

Cat. 6509 - Foundry Server Iron Interoperability
by Alison Gudgeon 29 Jan '01

29 Jan '01

Hi All, I wonder if anyone else has experienced the following problem and could perhaps offer a solution: Interconnecting Catalyst 6509 Short Haul GBICs up to a Foudry Server Iron SX with SC-SC fibre patch lead. The foundry sees a link light BUT the cisco see's nothing connected. What sprung to mind was auto neg. problems on the CAT but auto neg is not a supported option so it can't be this? Thanks in advance. Alison

3 2

Re: Proactive steps to prevent DDOS?
by Sean Capshaw 29 Jan '01

29 Jan '01

Sean, What you can do is enforce policy on your AS boundaries which: - rate limits ICMP - counts ICMP to detect floods, a monitoring script on your NMS can determine when the ICMP threshold has been exceeded and then determine the source and dest of the bulk of that ICMP traffic, then change your filters to discard ICMP to the host under attack while in parallel notify the NOC of the source or intermediary involved - For SYN floods - there may be no way to stop them but early warning can be achieved by counting both TCP SYN and total TCP and when the ratio of TCP SYN to TCP exceeds your threshold you can notify the NOC of the incoming intfc. When you understand the characteristics of the attacks or probes you are trying to stop, there are some powerful filtering and counting techniques which can be left in place at your edges and used in conjunction with monitoring scripts. Thanks Sean --- Sean Donelan <sean(a)donelan.com> wrote: > > Ok, Yahoo, Ebay, Amazon and Microsoft have all made > essentially the > same statement after being hit by a DDOS: "taken > steps to > improve protection of their networks from this type > of attack." > > My question is What are these steps, and why can't > people take them > before they experience a DDOS? > > Is there some magic command I can put into my router > to help protect > my network from a DDOS, or is this just PR fluff to > make it look like > the corporation is doing something. But in reality > there is nothing > you can do, but wait for the attacker to get bored > and stop on their > own. > > > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/

3 2

Re: Proactive steps to prevent DDOS?
by Sean Donelan 29 Jan '01

29 Jan '01

On Fri, 26 January 2001, John Hawkinson wrote: > > > This is the "state a fact that might be wrong to poll for dissent," approach? > > > > Yep. > > I don't find it a very pleasant style of discourse. Fine, does this work better for you? Help me, what proactive steps can I take to protect my network from a DDOS?

8 8