[j-nsp] Dynamic blocklists/blacklists...?

[Rafal Szarecki (WA/EPO)]

Well IMHO it is possible to filter-out base on source IP, without dymamic changes in configuration and with BGP bases anouncment of wrong source addresses.
And this should works for older SW/standard BGP.

1) Write policy for forwarfing-table which classufy all prefixes with BGP community "bed-source" to source-class "source-to-discard".
1a)(optionaly) Write policy for forwarfing-table which classufy all prefixes with BGP community "victims" to destination-class "victims".
2) Write firewall-filter which match on source-class="source-to-discard" (AND optionaly destination-class="victims") with action discard.
3) apply filter on output direction of interfaces

This is not as granular as BGP-flow.
This consumes one of 128 avaliable source/destination-classes.
This requires application on multiple interfaces on edge router. (mostly core facing)

But It should work. And Standard IPv4 BGP is enough.

(I was not test this. Just share an idea. If somebody will do thest, then please tell me about results)

Rafa³ Szarecki JNCIE

skype me <callto://Rafal_Szarecki/> 



> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net 
> [mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of Chris Morrow
> Sent: Wednesday, August 17, 2005 3:15 AM
> To: Jeff Aitken
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Dynamic blocklists/blacklists...?
> 
> 
> 
> 
> On Tue, 16 Aug 2005, Jeff Aitken wrote:
> 
> > On Tue, Aug 16, 2005 at 07:30:10PM +0000, Chris Morrow wrote:
> >> 1) setup dsc0 interface with /30 address
> >> 2) setup dsc0 interface with output acl content:
> >>    filter drop-all-count {
> >>      term deny-count {
> >>         then count deny-dsc0 discard;
> >>      }
> >>    }
> >> 3) reset nexthop or set nexthop in quagga/bgpd to /30 far-end
> >
> > Unless I'm missing something, this only works for dst-ip based
> > filtering.  If you have a list of bad src-ips (e.g., from
> > IDS/Arbor/whatever) and want to throw away traffic from them, you
> > need something else due to the aforementioned difference in how
> > Cisco & Juniper implement the uRPF check.
> >
> 
> oh yea... hrm, silly me. I was trying to avoid a dynamic 
> update to the 
> config for you :( oh well.
> 
> >
> >> be happy, don't do 'dynamic' filters....
> >
> > Agreed; my preference would be for Juniper to mimic the 
> Cisco behavior
> > (i.e., it should be possible to configure the box such that the uRPF
> > check FAILS if the route to the src-ip of an incoming 
> packet recurses
> > to null0) but as I recall they said that this was hard/impossible.
> >
> 
> I'm not clear as to why it would be 'impossible' for them to 
> do it, but 
> I'm just a chemical engineer :)
> 
> > However, as Pedro notes, the distributed flow-spec approach gives
> > you more granularity such as the ability to filter based on src-ip,
> > proto, port, etc.  It probably won't be long before your favorite
> > IDS/DDoS detection software will give you the option of injecting
> > filters this way... which is scary. :-)
> >
> 
> for that I'd look at TIDP... which is a 'competitor' 
> (alternative?) to 
> flow-spec... TIDP is supposed to give you a daemon-like 
> functionality on 
> any end system that could ask for 'help' from the upstream networking 
> devices. Oh well, like many things in the networking world, 
> there are more 
> than 1 ways to skin the cat.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>