North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...

  • From: Alan Hannan
  • Date: Fri Dec 20 20:53:04 1996

  mileage will vary with provider and the person within the
  company with whom you're working .  while ideally results would
  just appear, I do believe that with proper escalation and 
  persistence, you can get assistance.  your sales person can be 
  of help here.

  i know that uunet and mci do give sig. weight to syn attacks,
  and will work to determine the source.  I'm sure others do too.

  -alan

] 
] Except for one small problem, Unless you're _HUGE_ most NSP's (ie. MCI,
] sprint, uunet) don't give a flying fuck and won't spend the time and
] manhours it takes to track these things down. At one point one of our main
] machines was being synflooded on almost every port, mci refused to do a
] thing about it because it would 'take too long'.
] 
] On Fri, 20 Dec 1996, Alan Hannan wrote:
] 
] > 
] > 
] >   why even do that?  i'm not sure i want you triggering security
] >   mechanisms on my routers.  Especially with the overhead
] >   implications, though that is the thread we're currently in [may it
] >   die soon].
] > 
] >   building an acl that allows packets matching those you're
] >   interested in, and applying it to 'debug ip packet ACL detail'
] >   is fairly simple.
] > 
] >   just sit there doing 'clear ip cache A.B.C.D W.X.Y.Z'.  Find 
] >   the next hop it's coming from, trace it along, mail your 
] >   friendly peer or transit provider, or mail your friendly hacker's
] >   admins.
] > 
] >   granted, this is limited to the domain of routers you control, 
] >   but it's pretty effective for finding out where the syn attack is
] >   coming from.
] > 
] >   this assumes the people who are dumb enough to keep syn-ing 
] >   continue to be stupid enough to use originating source addresses 
] >   like 234.231.0.33.
] > 
] >   -alan
] > 
] > 
] > ] > 3) Deal with it legally.  This is what the telco's do.  It implies that we
] > ] > would need real mechanisms for tracking down offenders.
] > ] 
] > ] 	Personally, I'd like to see a protocol that allows you to ask a 
] > ] router to which you were directly connected to stamp an interface ID on 
] > ] all incoming packets bound for a particular network. You could then trace 
] > ] back router by router, interface by interface, where the packets were 
] > ] entering a block of cooperating providers.
] > ] 
] > ] 	Thus if I saw an incoming flood of SYN packets or ICMP echoes 
] > ] with forged origin addresses, I could ask my router to ask all its direct 
] > ] peers to begin stamping interface numbers (and/or interface IPs) on the 
] > ] packets they send to me. My router would eat those numbers/IPs so traffic 
] > ] would appear unaffected.
] > ] 
] > ] 	Then my tracing tool would know which interface the packets were 
] > ] coming in on and could ask that router to do the same thing (on a 
] > ] hop-by-hop basis for security reasons). Thus I could track it back to a 
] > ] specific enough interface path that perhaps an automated method to 
] > ] install a filter would be sufficient.
] > ] 
] > ] 	This stuff needs a lot of work, but might be a direction that 
] > ] would both facilitate emergency filtering and effective tracing for IP 
] > ] packets with forged origin addresses -- assuming the packets have enough 
] > ] in common to allow them to be detected (all pings, or heavy load, or all 
] > ] to same destination IP).
] > ] 
] > ] 	David Schwartz
] > ] 
] > 
] 
] [-]                  Brett L. Hawn ([email protected])                           [-]
] [-]                Networks On-Line - Houston, Texas                       [-]
] [-]                           713-467-7100                                 [-]
] 

- - - - - - - - - - - - - - - - -