September 1996 - Test - lists.nanog.org

Re: New Denial of Service Attack on Panix
by Paul Ferguson 18 Sep '96

18 Sep '96

I'm wondering if this is not quite the panacea that it appears. More thought is certainly required here... asymmetry being a problem that leaps to mind. - paul At 01:02 PM 9/17/96 -0700, Vadim Antonov wrote: >This is the excellent idea! Actually, router vendors may simply >add a feature which shuts down the interface if SYN/SYN-ACK balance >is too bad -- thus disconnecting the hacker-to-be. > >Of course, that balance may be decaying with time, so repeated >unsuccessful attempts to connect won't trigger alarms. > >--vadim > >Forrest W. Christian <forrestc(a)iMach.com> wrote: > >Maybe I'm missing something here, but wouldn't these Denial of Service >attacks cause a severe mismatch in the numbers of SYNs and SYN-ACKs on a >given router interface? > >If so, then couldn't we just sweet-talk cisco into providing 5 minute >counts of syns and syn-acks on an interface? > >

2 1

please unsuscribe
by GES Customer Support 18 Sep '96

18 Sep '96

please unsuscribe us from these lists as it is flooding us and all of the users we have on lists connected to this list. Thankyou. Support(a)jvnc.net Support(a)ges.com

1 0

advisory attribute in IRR
by Marc Slemko 18 Sep '96

18 Sep '96

Can anyone give me a pointer to information on what the advisory attribute in the IRR does and who pays any attention to that attribute? Thanks.

6 10

Re: router syn/syn-ack/ack alarming...
by Guy T Almes 18 Sep '96

18 Sep '96

Vadim, The case for ratio-based techniques is stronger as a means for a NOC to detect a strange situation and investigate it than as a means to automatically shut down an interface. Note that, given your 'opposite direction' idea, I could shut down service on campus 'A' by [1] logging into any host on campus 'A', [2] launching an attack that might not be harmful in itself but which would trigger the auto shutdown you advocate, and then [3] sitting back and watch all of campus 'A' get shut down with the presumptive blame focused on them. It's still a denial of service attack. The problem is not with detecting the ratio imbalance, but with simple deterministic response to it. That determinism could be used by an attacker. In sum, I like the idea of detecting the problem and rapidly tracing it, but I'm skeptical about a totally automated response to it given our current low level of experience with it. -- Guy At 05:58 PM 9/17/96 -0700, you wrote: >Regis Donovan <regisdo(a)microsoft.com> wrote: > >>um... maybe i'm missing the clue here, but if the router vendors add >>something that shuts down an interface if the SYN/SYN-ACK/ACK ratio >>becomes too bad make it *easier* for me if i'm doing a denial of service >>attack on a host? > >No, you took the "anti-SYN" shut-off in opposite direction. > >ISPs could install the asymmetry shut-off (why stop at SYNs / SYN-ACK pairs?) >enforcing rough balance of SYNs coming from customer and SYN-ACKs coming >back to customer. If the traffic is legitimate, the balance will hold. >Any attempt to flood by that customer (intentional, or unintentional, by >a broken software) will cause massive disbalance. > >The equivalent filter on victim's side won't see those SYNs and SYN-ACKs, >simply because thet are going in opposite direction. > >>instead of denying service to a given host, all i have to do is drive >>the router into alarm mode so it shuts off the interface and then i get >>to deny service to an entire segment and everything downstream from that >>segment... > >Yes, the defense may be multi-staged. I.e. if a local ISP does >not enable anti-flooding defenses on its own customer links, it'll risk >backbone ISP shutting its entire operation. > >BTW, telcos use the statistical traffic analysis (bit-density monitors >is the most trivial example) to isolate troubles for years. > >--vadim >

1 0

Re: SYN floods
by Paul Ferguson 18 Sep '96

18 Sep '96

At 02:36 PM 9/17/96 -0700, Time Keeper wrote: >It is also important to remember that the SYN attack is only one in a class >of one-way denial-of-service attacks. While hardening the servers on the >net against this kind of attack is important (and is the province of the >server/OS vendors, not the router or firewall vendors), the most effective >way to end a denial of service attack is to trace it to its source, and >terminate it there. > And terminate the perpetrator. ,-) > >It is time for a Best Common Practice document. > > Erik Fair > Erik, I volunteer to co-author. Please contact me if you are interseted in getting this document put together RSN. - paul

1 0

Re: router syn/syn-ack/ack alarming...
by Paul Ferguson 18 Sep '96

18 Sep '96

If it were such a clean-and-dry issue, believe me, we 'router vendors' would be happy to implement this knob; but alas, there are several valid instances where the SYN/SYN-ACK/ACK conversation ratio is not quite predictable. In any event, we are not sitting idly -- more info as it becomes available. - paul At 01:23 PM 9/17/96 -0700, Regis Donovan wrote: >um... maybe i'm missing the clue here, but if the router vendors add >something that shuts down an interface if the SYN/SYN-ACK/ACK ratio >becomes too bad make it *easier* for me if i'm doing a denial of service >attack on a host? > >instead of denying service to a given host, all i have to do is drive >the router into alarm mode so it shuts off the interface and then i get >to deny service to an entire segment and everything downstream from that >segment... > >here's to better bang for your cracker-kiddie buck... >--regis >

1 0

syn attack and source routing
by Brett D. Watson 18 Sep '96

18 Sep '96

i'm surprised there has been no discussion of turning off source routing on major backbones to help alleviate this problem. all of the focus seems to be on the edges of the networks when in fact the attackers are "running right up the middle". i'm not disagreeing that providers need to filter on the edges but the "big guys" are just as responsible as the "little guys". i know what a can of worms this is because source routing is quite useful in tracking down network and routing problems but it seems to me the danger it imposes today outweighs it's usefulness. -brett

2 1

Re: A modest proposal
by Sean Donelan 18 Sep '96

18 Sep '96

>Tracking down hacked machines would be quicker. Sometimes you might >be able to track back to the source where you could pull the ANI >or callerid information out of the radius accounting logs and have >someone knocking on their door. You only have to do this for 1 in 10 >attacks before rumors spread around the hacker community and it stops. I hate to tell you, but ANI and caller-id can be spoofed too. However, I agree that encouraging as much source filtering as possible would be "a good thing." Just as long as people don't get the idea that source filtering would make authentication by source IP address any more secure than authentication by caller-id. Now, if we could just get the phone company to not charge 1,000% markup on caller-id, we'd have it on all our modem lines now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

New Denial of Service Attack on Panix
by Kent W. England 18 Sep '96

18 Sep '96

Dear NANOG/IEPG Folks; As you should know by now from reading the papers, Panix, the first ISP in NYC, has come under a new denial of service attack. The Wall Street Journal quoted Bill Cheswick to the effect that the attack is "unstoppable". Almost, but not quite, true. It's true that there isn't anything that Panix can do on its own to stop this attack. It's true that it would be hard to verify source addresses at MAEs and NAPs. But we could all verify source addresses at the first hop entry points. And get default route and unauthorized transit protection to boot. I'd like to know what the community thinks can be done to deal with an escalation of these attacks should this occur. Are you doing any source address verification now? Are you doing anything to help Panix? Could you? How seriously do you take this threat? If Panix were to go out of business and Bob Metcalfe wrote a column on it, ( :-) do you think we would have to deal with it together then, or can we sit tight and expect it to blow over? After all, it's easy to dump chemicals in the reservoir, but we still drink the water, right? Thanks. --Kent ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe(a)6SigmaNets.com Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

20 44

Re: A modest proposal
by Daniel W. McRobb 18 Sep '96

18 Sep '96

> Currently, anyone can program their computer to repeatedly dial a > given business phone line and fill up a company's inbound phone lines, > making a denial of service attack. Why isn't the phone system about > to die because of it? > > The phone company keeps a record of every incoming and outgoing call > on every line, and performs all sorts of analysis on time of day and > carrier, and who gets paid for it. I think that 50% of the cost of > providing phone service is the accounting and billing. However, anytime > one has a problem with obscene callers, war dialers, etc, you call > the police and bingo, the men in blue are knocking on the door of the > perpetrator. The caller could dial from a payphone, etc, but what > you've essentially done is make it more dangerous/expensive to conduct > this activity than what it is worth. People that do this sort of > activity are usually cowards, because they're not bold enough to > park a truck bomb outside the object of their hatred. Up the ante, > and they're out of the game. > > I've been following some of the activity on various IP accounting > schemes and the size of those nifty matrices, but frankly, ISPs need > to spend the money to make this a reality and keep accounting data > for at least several days or a week. > > Now I'm a systems guy rather than a router guy, > so I'm not going to even propose that this take place in the router > or somebody will be lecturing me about silicon switched route > processors or something similar. I used to do it with ip accounting > on a cisco and perl scripts to yank the information off. This is > still a reasonable approach for small sites. It seems to me that a > good workstation setup for accounting on the segments attached to the > interexchange points could do all of this adequately. You'd need a > good freeware software package and preferably a web interface that > could be accessed by the right people at the right time. The web > interface would take 10 times as long to write as the collection > software. Once a few of the large carriers make this a prequisite for > peering, it would be widespread. Unfortunately, it's currently harder to do this from a workstation (at least all that I've seen) than it is from a router. I've yet to see a w/s that'll sniff at better than 4-5K pps sustained, and that's not even accounting for disk I/O and other issues. If someone knows of a w/s that can do this at pps rates in excess of 40,000 pps (even better, 100,000 pps so I don't have to search yet again next year), that won't cost me 4 mortgages, I'd love to hear about it. The only thing I've seen that'll do this to date is the oc3mon stuff, and that currently only works for OC-3 fiber. I'm not so much interested in actually deploying such boxes all over the network, but they sure would be nice to have at hand. I hate to say it (particularly since it's been said over and over, recently by Curtis), but I think the best bet for doing this is a hook in the forwarding code on the routers to capture X bytes of 1:N packets, aggregate a handful of them in memory, then shove them out a private interface. N of 1 would be nice, as would X of a large enough value to hold IP and TCP headers, IP options, and the link encapsulation (128 makes a nice word-boundary value and is what we used on the NSFNET) but I could probably live with N of 50 (again what we used in the NSFNET days, and I traced two SYN floods a few months ago w/ only 1:50 sampling even though very few packets were sent according to the site; they were running tcpdump... unfortunately, the folks owning the peer at the border I tracked it to were unable to help me track it further since they didn't have access to this kind of data). Daniel ~~~~~~

1 0