- Test - lists.nanog.org

NANOG Meeting
by Pam Ciesla 18 Sep '96

18 Sep '96

NOTE: Hotel rooms are in high demand. If you are planning on attending this meeting please reserve your hotel ASAP. I have had hotels calling requesting that room blocks be released because they a waiting list for rooms on the meeting dates. Pam Ciesla

1 0

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