Not to beat an already-decaying horse, BUT...
I'm currently in the process of setting up a new border router, and the
recent debate on the above topic got me wondering what the best practice
filtering policy is? Is there one?
And what do people put in place in terms of anti-spoofing ACLs and such?
There's a wealth of information on these topics, but no real consensus.
Or am I just reopening an ugly can of worms here?
TIA,
Recent versions of IOS support a cool feature:
"ip verify unicast source reachable-via any"
which can be installed on interfaces. This will silently drop
(assuming you're using cef) packets sourced from prefixes that you do
not have a route for.
ie: if you don't have 10/8 in your routing table, and someone
sends you a packet sourced from 10.0.0.3 it will get dropped.
that will drop all your rfc1918 space (with the obvious caveat of if
you route it) at the edge or in the core easily.
as for non-packet filters, i defer to the plethora of threads
- jared
Date: Tue, 09 Oct 2001 07:58:19 -0700
From: Grant A. Kirkwood <grant@virtical.net>
I'm currently in the process of setting up a new border router,
and the recent debate on the above topic got me wondering what
the best practice filtering policy is? Is there one?
And what do people put in place in terms of anti-spoofing ACLs
and such? There's a wealth of information on these topics, but
no real consensus.
+ If you're running BGP, filter your as-paths and netblocks to
avoid any unwanted redistribution. This is always a bad thing,
and long as-paths don't necessarily rule out a path being
taken; remember that local-pref overrides as-path length.
If it's an edge router, you needn't worry too much about prefix
length -- they're already filtered for you.
+ You want to prevent forged outbound packets. They have no
valid[1] use, and forged packets make tracing DoS attacks a
pain.
[1] I recall hearing that some satellite downlink Web service
required the ability to send packets from their netblock.
However, you can selectively allow these, as you would you own
netblock.
+ Disallow 10/8, 172.16/12, and 192.168/16 -- no need for them to
go anywhere.
Eddy
Howdy, all.
And what do people put in place in terms of anti-spoofing ACLs
and such? There's a wealth of information on these topics, but
no real consensus.
Perhaps this well help:
http://www.cymru.com/~robt/Docs/Articles/secure-ios-template.html
I am ever on the quest for input, feedback, and suggestions, so
please feel free to comment! Please send all feedback directly to
me.
Thanks,
Rob.
I'm currently in the process of setting up a new border router, and the
recent debate on the above topic got me wondering what the best practice
filtering policy is? Is there one?
I don't think so. If you want to filter to keep your routing table small,
filtering out all /24s is the way to go. These are 60% of the routing
table. Even in class A and B space 40% of the announcements is individual
/24s. Most people that announce a /24 are also reachable over an aggregate
so you wouldn't break too much connectivity.
If you want to filter against bad aggregation, you should look at class A
and B space and 192/8, there is a lot of that going on there, but usually
on "valid" prefix lengths such as /20 in A and /16 in B. So if you want to
filter those routes you'll have to do it on AS number, and you break
connectivity. But you can refuse to peer with ASes that don't aggregate
without having a good reason. (And if there is one for what's going on in
24/8, I'd like to know.)
And what do people put in place in terms of anti-spoofing ACLs and such?
There's a wealth of information on these topics, but no real consensus.
Depends on your paranoia level. You should always refuse incoming packets
with local source addresses. Outgoing packets with non-local source
addresses are bad, and incoming ICMP redirects aren't good either. You
should probably have filters that implement all of this at your border
routers, disable source routing and directed broadcasts (on every
interface of every router!) and route 10/8, 127/8, 172.16/12 and
192.168/16 to the null interface. That should be enough for most people.
Others like to filter more aggressively, for instance all non-allocated
address blocks and things like the official test network 192.0.2.0.
Iljitsch van Beijnum
a message of 18 lines which said:
I'm currently in the process of setting up a new border router, and the
recent debate on the above topic got me wondering what the best practice
filtering policy is? Is there one?
I'm interested to see if people filter route anouncements on the basis
of registered routes in an Internet Routing Registry. In our area
(Europe), the RIPE database typically contains less than half of the
routes which are actually announced. I assume it is not better in
ARINland.
On the basis of inetnum objects (network addresses, not routes), it is
a bit better in coverage but you cannot use inetnum directly in a
comparison, you have to check that a BGP announce *includes* at least
one registered inetnum.
To summary, I dropped the idea. Does anyone implemented it?
When I worked at Tiscali (World Online) Denmark, we did prefix
filtering on our peers, the results of that can be seen on
http://as8807.net/dixirrstats.txt (Though that is old, january this
year)
I believe that TeleDanmark also still do IRR filtering, and I know of
several providers in Denmark who are ready to follow suit as soon as
some of the "worst IRR-offenders" have updated their IRR records (which
actually has happened already)
If you decide to implement IRR filtering you may want to see how your
peers perform in the IRR area by using a small utility, which can be
downloaded from http://noc.tele.dk/util.html. This is the utility that
was used to produce the stats for Tiscali's router.
Has anybody else received one of
these emails? I don't have an issue
related to this, but I am concerned that
this will drive up the costs of maintaining
and improving my infrastructure.
-bradly
Less than a week ago Cisco TAC recommended DRAM from the Approved Vendor List to me. I hope this is not true.
-Paul
Bradly,
Can you forward me a copy of that email and
I'll verify it for everyone?
Thanks,
rodney