Tracking stealth portscan/pepsi attacks

Hi,

On Fri, Sep 03, 1999 at 02:18:58PM +0200, Lars Marowsky-Bree wrote:
> > On our external interfaces from our upstreams we deny packets with a
> > source address coming from one our network blocks.
> 
> We also filter private addresses & martians. Sometimes a few of those come
> through.

While I'd like to do that, I'm still not sure what's worse - seeing
192.168.x.y addresses in an outgoing traceroute, or listening to customer
complaints about "why is there a line ' * * * ' in my traceroute output?
something must be wrong!" when filtering those.

So right now, I let packets with RFC addresses pass (from upstream, not
from our customers).  But I still hope that people will stop using them
for transit networks.

> And on the outgoing interfaces we filter packets going to our own netblocks,
> so that we don't accidentially leak because of fucked up routing.

Interesting idea.  I'm not sure how that problem could happen, but maybe
our network's topology is too simple :-)

> And then there are the filters on the BGP4 sessions to prevent someone from
> injecting bogus routes into our AS (remember that EBGP learned routes take
> precedence over IGP, and more specific routes always take precendence, so if
> you don't filter correctly, someone might hijack one IP from your network).

Plus filters for the transit networks on the usual exchange points
(DE-CIX, MAE-Frankfurt, etc.) - because that could hose up routing 
massively if one of those networks appears in your iBGP...

Thanks for the tip with "filter bogus routes from our own network blocks", 
I didn't yet think of that problem, but it's certainly worth considering.

> > Interesting enough, we don't observe many attacks - what we do see is LOTS
> > of broken end user configurations (leaking RFC 1918 networks, customers
> > leaking IP addresses from other ISPs, ...).
> 
> Yeah. But it also helps to prevent smurf attacks etc.

Definitely - that's why I did it, but I just wanted to note that there
are (well, "we observe") much more misconfiguration problems than active 
attacks.

Gert Doering
        -- NetMaster
-- 
SpaceNet GmbH               Mail: netmaster at Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299