September 1996 - Test - lists.nanog.org

Re: router syn/syn-ack/ack alarming...
by Vern Paxson 18 Sep '96

18 Sep '96

> have something in their logs like SYN/ACK RATIO 33:1 POSSIBLE HACKER > ATTACK which will make them sit up and take notice. I don't see how in reality to make the syn/syn-ack/ack ratio work soundly. It seems too easy for the cracker to synthesize bogus syn-ack's or ack's to manipulate the ratio however they please. The bookkeeping to tell a true syn-ack or ack-syn-ack from a bogus one entails keeping around connection state, and suddenly the cheap ratio gets expensive. Vern

5 5

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

18 Sep '96

At 01:57 PM 9/18/96 -0700, Vadim Antonov wrote: >And half of them wouldn't know what SYN/ACK ratio is. half? Now you're being optimistic ;) Justin Newton Internet Architect Erol's Internet Services

1 0

Re: router syn/syn-ack/ack alarming...
by Vadim Antonov 18 Sep '96

18 Sep '96

Michael Dillon <michael(a)memra.com> wrote: >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. Ah, you're an optimist. Most sysadmins would simply ignore whatever warnings they get as long as their internal users aren't complaining. And half of them wouldn't know what SYN/ACK ratio is. --vadim

3 2

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

18 Sep '96

Please forgive me for ignoring previous posts of this discipline; Has this topic been added as an agenda item for NANOG? - paul At 04:59 PM 9/18/96 -0700, Michael Dillon wrote: >On Wed, 18 Sep 1996, Michael Dillon wrote: > >> Wouldn't the ratio be calculated from outgoing SYN's and incoming ACK's? > >Ooops. I meant incoming SYN-ACK's with the emphasis on a ratio between >outgoing and incoming. > >Michael Dillon - ISP & Internet Consulting >Memra Software Inc. - Fax: +1-604-546-3049 >http://www.memra.com - E-mail: michael(a)memra.com > > >

1 0

Re: router syn/syn-ack/ack alarming...
by Vern Paxson 18 Sep '96

18 Sep '96

> From: Michael Dillon <michael(a)memra.com> > ... > Wouldn't the ratio be calculated from outgoing SYN's and incoming ACK's? There are two ratios that could be calculated and it's not clear to me which one we're talking about here. The first ratio is the number of SYN-ack packets sent in one direction vs. the number of acks-of-SYN-ack packets coming in from the other. These should be about equal. A skew indicates a likely flooding attack. But computing this ratio requires keeping around per connection state, since the ack-of-SYN-ack packet otherwise looks like any other ack. The second ratio is the number of SYN packets sent in one direction vs. the number of SYN-acks in the other. This ratio is a much easier to measure but also a much less reliable indicator of a SYN flooding attack. In particular, SYN packets can elicit RST's or ICMP's instead of SYN-acks, and they can also elicit no response whatsoever. Furthermore, the cracker can, while flooding host A with SYN's, in addition also flood host B *and follow up immediately with a RST packet* that clears out B's state. This second stream can be maintained indefinitely, and will have the effect of bringing the count of SYN-ack's quite close to the count of SYN's, since B is always able to generate the SYN-ack. Vern

1 0

Re: BCP writers
by Paul Ferguson 18 Sep '96

18 Sep '96

Michael, I'm traveling at the moment -- could you provide a quick synopsis of the people that have expressed an interested in writing this document? I really don't have the time at the moment to surf through the 2500 messages that wait me. Thanks, - paul At 09:23 AM 9/18/96 -0700, Michael Dillon wrote: >On Wed, 18 Sep 1996, Hank Nussbacher wrote: > >> 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. > >In the BCP document, please explain the difference between source routing >and source spoofing as well as SYN flooding. And please cover source >address filters for both incoming and outgoing. > > >Michael Dillon - ISP & Internet Consulting >Memra Software Inc. - Fax: +1-604-546-3049 >http://www.memra.com - E-mail: michael(a)memra.com > > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

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

18 Sep '96

For what its worth, we are looking at this. - paul At 04:32 PM 9/17/96 -0700, Leonid Egoshin wrote: >>From: "Forrest W. Christian" <forrestc(a)iMach.com> >> >> 5 minute SYNS: 123423 5 minute SYN-ACKS: 50000 >> >>Then, if the ratio got too high, it can start yelping about "Potential SYN >>D-O-S Atttack in progress on Interface Serial 1" > > I suggest to check not only ratio (assymetric routing !), >but high number of SYNs to single host. > > - Leonid Yegoshin, LY22 > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: A modest proposal
by Paul Ferguson 18 Sep '96

18 Sep '96

At 07:19 PM 9/17/96 -0400, Allan Chong wrote: >Hmmmm. If I were a hacker, I would be doing my best to make sure that >my route to the victim was taking a path through as many foreign >speaking networks as possible. You'd have to speak Swahili and >Cantonese :) > TCP (and UDP) happens to be a global village. :-) - paul

1 0

Re: A modest proposal
by Paul Ferguson 18 Sep '96

18 Sep '96

At 06:51 PM 9/17/96 -0400, Robert E. Seastrom wrote: >This discussion of securing dialup servers is pointless. I guarantee >you that the 2000 packet/second SYN attacks we've been seeing are >coming from a compromised host on a high speed connection and not from >someone's 28.8k dialup connection. The hackers just take over a >machine, use it to launch their attacks, and disappear into the jungle >if we manage to find the particular machine they're using tonight. > >Harden your servers, filter on all non-transit ports on your routers, >but let's let the how-to-do-filtering-on-terminal-servers discussion >die, OK? > > ---Rob Rob, 'Securing dialup servers' discussion is certainly not pointless; there are certainly considerations that need to be taken in any remote access environment -- that's a fact. Please don't be so quick to dismiss anyone's ideas on this topic; we're going to need full-force input from everyone in the operational world. - paul

1 0

Re: A modest proposal
by Kelly J. Cooper 18 Sep '96

18 Sep '96

On Sep 18, 6:54pm, Robert E. Seastrom wrote: * * From: Dalvenjah FoxFire <dalvenjah(a)dal.net> * * * * I haven't used any myself, but apparently there are several software * * packages out there with a pretty graphical front end, complete with * * Hollywood-style "Click to destroy machine" buttons and menus. * * * *Uh huh, right. If you ever actually see anything like this, lemme know. * * Ok, RS. * * One piece of software is called UpYours! and it's a mailbombing * tool built by a group called "Global kOS" to run over Windows95. * It's got a lovely interface including buttons for "BOMB" "ULTRA" * and "STOP" with an input window for "Countdown" start & stop * *How did the topic get changed from packet-spewing attacks to *application-layer attacks? It didn't. Dalvenjah stated attack software packages with graphical front ends existed. You expressed doubt. I responded with evidence. Just because this one happens to be application layer doesn't mean there aren't others out there to run any number of different attacks. The tools are being built. They are designed with ease of use in mind. How did the topic change from fighting network attacks to nit-picking? My point was the possibility for widespread use of simplistic attack mechanisms. Even if they're trivial to block, with enough attackers using them with enough varying patterns, saturation becomes the issue no matter what the exploit. Kelly J. -- Kelly J. Cooper Network Operations Security BBN Planet Corporation phone 800-632-7638 150 Cambridge Park Drive fax 617-873-6351 Cambridge, MA 02140 http://www.bbnplanet.com

1 0