North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: attacking DDOS using BGP communities?
Inline comments below... --Chris ([email protected]) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ####################################################### On Fri, 18 Oct 2002, Jason Lixfeld wrote: > > Interesting -- I was actually having a conversation about this very same > thing with a friend of mine a few days ago. The problem we had, was > that he had next-hop-self on all of his ibgp mesh routers. Does that > not make it difficult to put an ip next-hop in? Also, would that ip > next-hop be propagated throughout his mesh or would that same route-map > have to be present on all the edge routers? > Not difficult at all, I'll post out sample config bits before NANOG in Eugene :) (they are about half done... I'm just lazy) > The other thing we were toying with was a setting the administrative > distance for said black-holed route to be less than that of his igp and > having his IGP route to 127.0.0.1 or something. > Yikes... Just go with the simple solution :) Blackhole routes work just fine in bgp, sample blackhole route server configs exist at: http://www.secsup.org/Tracking/ for both Juniper and Cisco... and someone was going to forward me Foundry configs at one point too :) > The whole goal was to try and kill the route as close to the source as > possible so as not to have the traffic traverse the core. The question > is, how to? > Once you look beyond your ASN it gets very difficult to determine where the traffic is originating, unless the next ASN is terminal... Anyway, I'll get some configs at: http://www.secsup.org/CustomerBlackHole/ In the coming days. > -- > "AFAIK, I'm a BOFH for continually bashing you with a clue-by-four. > OTOH, if you would just RTFM every once in a while, my life would suck > *much* less." > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Frank Scalzo > > Sent: Friday, October 18, 2002 9:52 AM > > To: Saku Ytti; [email protected] > > Subject: RE: attacking DDOS using BGP communities? > > > > > > > > 701 has a blackhole community, 701:9999, basically it sets > > the next-hop > > to something blackholed on their edge so the DOS attack gets > > dropped as > > soon as it hits them. I have made use of this to kill at > > least one DDOS > > event. A global blackhole community may be difficult to achieve, but > > getting the majority of large providers to implement one is a good > > start. > > > > -----Original Message----- > > From: Saku Ytti [mailto:[email protected]] > > Sent: Thursday, October 17, 2002 5:23 PM > > To: [email protected] > > Subject: attacking DDOS using BGP communities? > > > > > > How feasible would these ideas be? > > > > 1) Signaling unwanted traffic. > > You would set community which would just inform that you are > > receiving > > unwanted traffic. This way responsible AS# with statistical netflow > > could easily automaticly search for these networks and report > > to NOC if > > both there is increased traffic to them and community is on. > > > > -would it be affective at all? Could your netflow parser use > > it easily? > > +wouldn't need big changes > > > > 2) 'TTL' community. > > You would have ~10 communities representing how many AS hops until > > route > > should not be advertised anymore. If you would experience DOS you'd > > start > > from TTL 1 and increase until DOS flow starts again, with any > > luck you > > would end up having very limited amount of AS# to communicate with > > in hopes of fixing their anti-spoofing filters and to catch malicious > > party. > > > > -just think about the amount of route-maps :> > > -you would need to flap the network possible 10 times == damped > > +some idea who to contact w/o co-operation of NOCs (can be hard) > > +wins you time, often DOS is over before you've reached 3rd AS number > > to ask where the traffic is originating. > > > > 3) 'null route' community. > > This would only be useful if it would mean that you are also > > accepting > > more spesific annoucement, preferally even /32. Most people > > are propably > > crying about the idea already, but if you plan it wisely with > > prefix-limit > > setting it might not be suicide. Just remember that all downstream > > prefix-limit+your prefices must be smaller than what your upstream has > > set for prefix-limit, if this is not done then your downstreams can > > effectively trigger your upstream prefix-limit killing your > > connectivity. > > How AS handles the 'null route' community could vary, others set > > next-hop to null0 other might set it to analyzer tool. Just that it > > shouldn't reach the other end anymore. > > > > -the obvious: explosion of global bgp routing table (no, not > > nececcarily) > > +effective, you'd instantly free your link from any DOS > > traffic to given > > destination. > > -- > > ++ytti > > >
|