- Test - lists.nanog.org

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 17 Sep '96

17 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 17 Sep '96

17 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 17 Sep '96

17 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

amusement
by Curtis Villamizar 17 Sep '96

17 Sep '96

***** Off Topic - Delete now if you are humor impaired! ***** Here's a recent incident and an earlier one I just found amusing enough to keep. These are both voice services, not data. I honestly wish I had saved more of these. There have been quite a few and some had some entertaimnent value. Please respect the "Reply-To". This *isn't* worth further discussion. Curtis ps- thought we needed some cheering up. If word gets out about this people might be reluctant to use voice services. ;-) pps- if IP service is as bad as Bell Atlantic Answer Call then people will leave their IP service provider so in a sense that's no joke. ------- Forwarded Messages Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by brookfield.ans.net (8.7.3/8.7.3) with SMTP id IAA06101 for <curtis(a)brookfield.ans.net>; Tue, 17 Sep 1996 08:56:07 -0400 (EDT) Received: by interlock.ans.net id AA06319 (InterLock SMTP Gateway 3.0 for ans-world(a)ans.net) Tue, 17 Sep 1996 08:56:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Sep 1996 08:56:41 -0400 Message-Id: <199609171256.AA04835(a)interlock.reston.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Sep 1996 08:56:41 -0400 X-Mailer: InterCon TCP/Connect II 2.1.2 Mime-Version: 1.0 Date: Tue, 17 Sep 1996 08:59:42 -0700 From: "Carol Harvey" <harvey(a)reston.ans.net> To: ans-world(a)ans.net Cc: ans-reston(a)ans.net Subject: Voice Mail Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline There is a system-wide outage of the Bell Atlantic Answer Call (Voice Mail) in the Northern Virginia Area. They are working on the problem and will restore voice mail as soon as possible. The good news is -- we get our own in-house voice mail with our new phone system this Friday. Carol ------- Message 2 Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by brookfield.ans.net (8.7.4/8.7.3) with SMTP id WAA12714 for <curtis(a)brookfield.ans.net>; Tue, 23 Apr 1996 22:54:14 -0400 (EDT) Received: by interlock.ans.net id AA13449 (InterLock SMTP Gateway 3.0 for ans-world(a)ans.net) Tue, 23 Apr 1996 22:53:27 -0400 Message-Id: <199604240253.AA13449(a)interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 23 Apr 1996 22:53:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 23 Apr 1996 22:53:27 -0400 Date: Tue, 23 Apr 96 22:53:25 EDT From: David Bolen <db3l(a)ans.net> To: ans-world(a)ans.net Subject: Elmsford phones: It's alive! @begin(heavy sarcasm) Well, that was fun... @end(heavy sarcasm) Ok, our local PRI to NYNEX has been restored. While the backup analog connections still require the PBX cards that are getting replaced tomorrow, since the primary route (the PRI) has been restored, all phone services should be back to normal. Direct dialing Elmsford extensions is again working, Elmsford users can make 800 number calls, and local calls from Elmsford are going out over the local circuits. For those interested... It turns out that my "lost" NYNEX technician did in fact find some problems in the basement (rather than in the NYNEX shelf in the lab, which only needed a fuse replaced), but it was in gear he wasn't in the right group to "touch". So when he finally showed up again (around 8pm) he informed me he had requested that the "Hi-Tech" group (T1 and data services) dispatch someone. Luckily, they work 24 hours, and are generally on top of things. A pair (lookie - _two_ techs showed up at once to work together, what a concept) got here by about 10:15pm, and everything was up and running again within 20-30 minutes, after replacing some gear in the basement. So it only took me about 55 hours to get an appropriate crew from NYNEX to show up to handle a 20 minute, "obvious" job... I don't know whether to laugh in relief that it's over or cry in despair over what it took.... But we're back up. - -- David ------- End of Forwarded Messages

1 0

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

17 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? Actually the phone system does periodically die from this. Just ask the White House switchboard operators about it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0