On 2010-04-04, Eugene Yunak <e.yu...@gmail.com> wrote: > On 4 April 2010 18:56, Pete Vickers <p...@systemnet.no> wrote: >> On 31. mars 2010, at 20.01, Claudio Jeker wrote: >> >>> On Wed, Mar 31, 2010 at 08:08:01PM +0300, Eugene Yunak wrote: >>>> On 31 March 2010 19:27, N. Arley Dealey <arley.dea...@gmail.com> wrote: >>>>> It would appear to me that antispoof and URPF achieve similar results. Is >>>>> there a reason to prefer one over the other? >>>> >>>> Not at all. antispoof blocks ip packets that came in from the wrong >>>> interface, while URPF blocks packets from "aliens" (no entry in >>>> routing table for the source address). Just look at the output of >>>> pfctl -sr >>>> >>> >>> Not at all. URPF does not only check if a route exists it also checks that >>> the route is pointing to the interface the packet came in. >>> >>> Antispoof is only for the LAN while URPF is actually capable of tracking >>> stuff further down. This is at the same time the problem of URPF if you >>> have asymetric routing URPF fails. Antispoof works in this case since it >>> is hard to get asymetric routing on the LAN. >>> >>> -- >>> :wq Claudio >>> >> >> >> uRPF (at least recent incarnations of it) can be /configured/ to drop packets >> based of presence of /either/ : >> >> - a matching FIB prefix outbound on the same interface the packet arrived on >> (strict mode) >> - a matching FIB prefix outbound on any interface (loose mode) >> >> you can also mask uRPF effect to only a subset of packets/prefixes with an >> ACL. >> >> >> pretty extensive explanation here: >> >> http://www.cisco.com/web/about/security/intelligence/urpf.pdf >> > > Do you realise that this is an OpenBSD mailing list, and we are > discussing OpenBSD's pf implementation of uRPF?
It's still relevant. PF has the things Pete specifically mentioned: - loose mode: use 'no-route' for this - ACLs, well you just restrict the rule operation: block in urpf-failed pass in from 1/8 But we don't have a few things discussed in the document which might be useful: - option to use an alternative table in the urpf/no-route lookup - drop incoming packets where the route lookup yields a blackhole/reject route (the 'If the adjacency of a route equals Null0...' enhancement). this is really nice, it lets you inject a route tagged with some community, have an associated 'match...set nexthop blackhole' in bgpd.conf, then you would be able to drop traffic *sourced* from that address at all your borders, without some special way to sync PF tables around.
