September 1996 - Test - lists.nanog.org

Re: router syn/syn-ack/ack alarming...
by Justin W. Newton 18 Sep '96

18 Sep '96

At 09:50 AM 9/18/96 -0700, Michael Dillon wrote: >On Wed, 18 Sep 1996, Guy T Almes wrote: > >> the source host. Syn/synack/ack ratio detection is complementary, since it >> could help detect an attack near the destination host. > >It could also help detect an attack near the source host which would help >*GREATLY* in tracing the perpetrator of the attacks. This ratio detection >doesn't need to shutdown anything, just syslog the fact so that admins >have something in their logs like SYN/ACK RATIO 33:1 POSSIBLE HACKER >ATTACK which will make them sit up and take notice. Ubfortunately the number of people who actually monitor their routers that closely is probably limited to the members of this list. We're much more likely to get people to filter their networks than to actively monitor anything. I am speaking from the background at having worked at a small ISP where if I wasn't there noone monitored anything basically until it started smoking. Justin Newton Internet Architect Erol's Internet Services

1 0

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

18 Sep '96

At 10:43 AM 9/18/96 -0400, Jeff Young wrote: > >i guess the one common thread of this discussion is that whatever >must be done, must be done on the edges of the internet. and that's >not a cop out, we have as many edge cases as we have connections to >isp's. > No argument here. - paul

1 0

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

18 Sep '96

> From: Hank Nussbacher <hank(a)ibm.net.il> > Subject: Re: syn attack and source routing > > Return-Path: <hank(a)ibm.net.il> > X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > 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. i should have been more specific. i don't like the idea (at all) of breaking traceroute -g either. i guess in a more general sense i should ask "just how dangerous *is* having backbone-wide/internet-wide loose source routing enabled?". -brett

2 1

RE: NANOG Meeting
by Danny Stroud 18 Sep '96

18 Sep '96

Yes, I do want to get a room. Kathy, can you reserve a room for me the same nights Randy Bush is there? Thank you. we will need to make reservations for all Whitney, Chris and John. I think Andrew and Randy are already set. We are going to have a staff meeting pre-NANOG. des ---------- From: Pam Ciesla Sent: Wednesday, September 18, 1996 8:58 AM To: nanog(a)home.merit.edu Subject: NANOG Meeting 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: 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