Tracking stealth portscan/pepsi attacks

Havard.Eidnes at runit.sintef.no wrote:
> 
> > Last month I described the idea of an special prefix access
> > list on de.comm.internet.routing that basically solves that
> > problem.
> >
> > The syntax would look something like this:
> >
> >  'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks'
> >  'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks'
> >
> > It simply conscructs an automatic ip prefix access-list based
> > on the prefixes received/announced to/from the BGP peer. This
> > has the cute side effect that all ip filters can be done in one
> > place; the bgp configuration.
> 
> Umm, how is this significantly different from doing RPF (Reverse
> Path Forwarding) checks for unicast packets, as I described
> earlier, and as already implemented by Cisco?

It allows asymetric routing.

> If I understand what you're trying to do correctly, doing the
> "received-networks" would be to just turn on RPF checking on the
> incoming interface from the neighbor, while doing "announced-
> networks" will mean that you either have to make sure you have
> RPF checking on all your edges or that all interfaces on this
> particular customer access router has RPF checking turned on.

Well...

What I imagine is an prefix based packet filter (no rule list). This
would be as fast as the routing table lookup.

Lets have a look what the router does with that feature:

 1. ip packet comes enters through interface s0/0

 2. ip packet source address gets checked against prefix filter. The
    prefix filter contains and allows only prefixes received from
    bgp neighbor 1.2.3.4

 3. process the packet as usual

> > The 'permit received-networks' part looks pretty promising for
> > an easy implementation because the router has to perform an bgp
> > table lookup anyway for each incoming ip packet.
> 
> Um, that's not quite correct.  The router does a forwarding table
> lookup for the destination address in each packet when doing
> packet forwarding; the forwarding table is being built from
> (among other sources) the BGP routing database.

Yes.

> Doing the RPF check for unicast packets adds a second forwarding
> table lookup for each packet (look up the source and see if the
> packet entered on an interface where we have a route pointing
> back out), so it does have a cost, but demanding CEF (as Cisco
> does) reduces that cost over the other potential alternatives.

The problem with RPF is that as doesn't work in environments with
asymetric routing.

-- 
Andre Oppermann

CEO / Geschaeftsfuehrer
Internet Business Solutions Ltd. (AG)
Hardstrasse 235, 8005 Zurich, Switzerland
Fon +41 1 277 75 75 / Fax +41 1 277 75 77
http://www.pipeline.ch    ibs at pipeline.ch