Re: Tracking stealth portscan/pepsi attacks
- Date: Tue, 07 Sep 1999 17:02:56 +0200
Havard.Eidnes@localhost 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@localhost
