- Test - lists.nanog.org

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

18 Sep '96

Alex, I agree with much of your analysis, but would argue that the two techniques of: - source address filtering and - syn/synack/ack ratio detection are *complementary* approaches, both of which have promise. Due to asymmetric routes and other reasons, neither seems very promising within core routers. Source address filtering, however, should become standard practice near the edge of the net and help control attacks near the source host. Syn/synack/ack ratio detection is complementary, since it could help detect an attack near the destination host. I am also a bit skeptical about the idea of automatically shutting down an interface upon noticing anomolies in the ratios, but that does not detract from the value of ratio anomoly detection as a valuable network management technique. -- Guy At 09:48 PM 9/17/96 +0100, Alex.Bligh 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? > >On "core" (whatever that means) you only need an extra couple of hundred >SYNs /sec to be passing through an attack, on many many 000s of SYNs >per sec. On customer facing routers, much easier just to block packets >with source addresses not on customer LANs. IE where your solution would >help, one can already fix the problem w/o a s/w change. > >Alex Bligh >Xara Networks > > >

2 1

Re: syn attack and source routing
by Hank Nussbacher 18 Sep '96

18 Sep '96

On Wed, 18 Sep 1996 03:17:27 -0400 Curtis Villamizar wrote: >If source routing is blocked at the end site it doesn't help any >toturn it off in the backbones and turning it off destroys the ability >to trace routing problems that customers report (short of finger >pointing to another provider or giving the customer the run around by >successive handoffs to other NOCs debugging, any "I can't get there >from here" is sort of hopeless if you can't traceroute -g). Since more and more are blocking source routing and breaking traceroute -g then those that block it at their router should at the very least make a WWW traceroute available from their system so as to diagnose those problems you mention. Almost all those that I have in my web site (http://www.ibm.net.il/traceroute) are customers connected to major ISPs. I think the 10 majors should have on their backbones a WWW traceroute as above. > >Curtis > Hank

2 1

Re: New Denial of Service Attack on Panix
by sob＠academ.com 18 Sep '96

18 Sep '96

Tim writes: > How about commercial organizations (such as NANOG, CIX) expanding > their charter to basic R&D into reinforcing security weaknesses > within their mutual are of commerical interest? Last I checked, NANOG was not a commerical organization. Tim, can you provide more information about this? -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

A modest proposal
by Allan Chong 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. 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. allan allan(a)bellsouth.net And no, I'm not volunteering for anything yet :)

10 15

Re: New Denial of Service Attack on Panix
by Guy T Almes 18 Sep '96

18 Sep '96

Kent, I liked the rest of your message more than the first sentence. I agree that this will be hard to accomplish. The key point, one that I hope everyone on the NANOG and IEPG lists take to heart, is your 200- year-old phrase that we will surely "hang together or hang separately". The Panix attack undercuts every enterprise that attempts to promise to users that they will be able to use the Internet to get their work done. I hope that users, providers, and vendors will cooperate on moving forward on all three of: - source address filtering near the edges of the network - improved TCP software in the hosts - improved technology and operational routines for tracing attacks. If one of these three thrusts is inconvenient to your part of the Internet, don't take much comfort in assuming that the problem will be solved by everyone making dramatic progress on the other two. -- Guy At 01:42 PM 9/17/96 -0700, Kent W. England wrote: >At 11:02 AM 9/17/96 -0400, Guy T Almes wrote: >>Nathan, >> I'm afraid that Kent is right about this one. >> >I wish that it were not so, but after reading the clever and insightful >approaches to tracking down the denial-of-service perps, I am pessimistic >about our ability to stay ahead in the escalation of this counter-counter- >measure warfare. I think that if we were able to trace the Panix attacker >that a future attacker would hit simultaneously from a half-dozen free >dial-up connections with a real random number generator and synthetic >SYNs to fool the router stat collector (or whatever it takes). I think we >are on the short end of the technology stick here. > >If the fit hits the shan and the attacks begin to escalate, we need to be >ready to cooperate on source address filtering at the periphery. It's one >of those cases of hang together or hang separately. Should we wait, like >the cell phone industry did with the cloning fiasco, until this gives us >a black eye? It's just too inviting to expect that we don't have plenty of >folks out there ready to pull this trigger on us. > >We need a general consensus in order for any one of us to justify the effort >required to install source address filters. That means that representatives >from major backbone ISPs must announce that they will install filters (not >at the MAEs) in response to this new threat and that they expect that their >peers will too. I'm not one of those major backbone ISP network >engineers, but I would hope that for the sake of all of us, that those who >are will roll their eyes heavenward, take a deep breath, and do what needs >to be done. I know it's easy for me to say, but nevertheless ... > >This is an excellent example of what the NANOG and IEPG are really good for. > >--Kent >

2 1

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