Network Operators and smurf

Mailman List Mirror (Read Only)
1

Hi all,

<rant>
  If were reading this list on a professional basis, we should be a
little clued, or at least attempting to get there. We're in the big
leagues now, read up on CIDR, figure out classless subnetting. To
advocate breaking legitimate routing because we, as an industry, don't want
to put in the time and effort to educate our end users is just a little
lame.
</rant>

  Had to get that off my chest.

  Anyway, it's been said here several times before, but I'll say it
again.

  To end the smurf type exploits, we need to do 2 things.

1. Routers/Gateways should be configured to prevent the transmission of
echo-request packets, out an interface, to a destination address identical
to the broadcast address of that interface, except in those cases where
specifically required.

  This means getting vendors to give us a knob, and having it
default to off.

This is the easy one folks, figuring out net-masks aren't that hard. The
transit providers might have problems with implementing this due to
hardware meltdown, but that's not where it needs to be implemented.

  !!Educate your (our) users!!

2. Routers/Gateways should be configured to drop all packets with
invalid source addresses.

  This is a little bit more difficult, particularly if your
multi-homed, but again, it's not the transit providers that are need to
implement this, its the end user.

  once more

  !!Educate your (our) users!!

No. 2 has the benefit of fixing all manner of ills.

The problem is us. This isn't a research network run and maintained by
the knowledgable. This is a business. We're selling a product, and if we
expect it to operate as advertised, it's up to us to educate those we sell
it to.

This is Mr. Pot, saying so long to all you kettles out there.

- --
Rusty Zickefoose | The most exciting phrase to hear in science,
rusty@mci.net | the one that heralds new discoveries, is not

2

The problem isn't us. It's cicso, and Bay, and Ascend, and... everyone
who won't put an anti-forging filter on their border routers so we
_can_ turn it on. The first time someone co-sues cisco, it'll get
fixed with 30 days.

Cheers,
-- jra

3

They put the software in. "We" just won't turn them on. We have seen the
enemy and they is us.

    --Dean

4

Off-line survey: if you operate a border router or dialup access server
(Livingston, Ascend, USR TC, etc), please mail me directly and tell me
1) whether your device has a know to llow you to drop incoming packets
with forged source addreses, 2) what it defaults to, and 3) how well
it's called out in the documentation. Please include specific model
numbers, and software release numbers if possible.

Do _not_ reply to the list; I'll summarize.

It's been my understanding that the knobs are in fact _not_ there,
Dean, but I'd be happy to be proven wrong.

Cheers,
-- jra

5

There isn't a simple knob, but then it isn't simple to know what a forgery
is. You to have tell the router. The router doesn't know what you and
other people "own", but you can tell it. I'd say there isn't a way to make
a simple on/off knob for that, because there isn't any way to tell who you
will transit for and who you won't.

On your outbound interface(s):

access-list 101 permit ip <yournet-1> any out
access-list 101 permit ip <yournet-2> any out
...
access-list 101 deny ip any any out

This allows only packets sourced from your networks to be sent.

Or, another perhaps better way is to only accept packets from your customer
networks which are sourced from those networks. Each customer interface
then has an inbound filter the blocks everything not sourced from your
customers network.

    --Dean

6

That was the idea. I was, as noted, mostly talking about router
interfaces with only one network (block) behind it. I gather a large
part of it comes from dialups, where the remote network is a /32.

in any event, I'm not sure I made the query explicit enough, from a
couple of replies I got: the knob I'm specifically interested in says
"don't forward packets with source addresses that can't be routed back
out this port".

Cheers,
-- jra

7

Well, there is a simple knob for this:

If the Knob is turned "ON", then any packet from a source address which is
not routed to the interface it came in on is dropped.

This works for static, dynamic, and all other kinds of routing. It will
solve the problem and is trivial to implement - if any of the vendors care.

8

Thanks, Karl. Precisely the precis I was looking for.

Cheers,
-- jra

9

And conversely, ..:

acce 102 deny ip <yournet> any
acce 102 perm ip any any
in s0
ip access-g 102 in

10

It doesn't work for asymmetric routing as you describe it above. If you
modify your criteria to be that there are no valid routes out that
interface, you would only break transient routing conditions, but
depending on how the router stores routes it may not be possible (or
desirable due to memory requirements) to implement.

John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801

11

Yeah, John, we know that. But I've rarely seen a /32 with asymmetric
routing. The vast majority (I speculate) of these problems happen on
the far side of border routers which are unlikely to be participating
in ASR, are they not? How far down is it being used?

Cheers,
-- jra

12

There isn't a simple knob, but then it isn't simple to know what a forgery
is. You to have tell the router.

That's what routing protocols are for, right? :slight_smile: I thought I had read on
cisco-nsp that 11.1CC implemented the long-discussed feature of not
accepting packets from an interface unless the router held a route for the
source address of that packet back out that interface, but I can't find
that message now. I wonder what that does to forwarding rates on VIP2s and
12000s.

Or, another perhaps better way is to only accept packets from your customer
networks which are sourced from those networks. Each customer interface
then has an inbound filter the blocks everything not sourced from your
customers network.

As I told Jay, we have modified our RADIUS server to do exactly this on the
fly for 3com NETservers, 3com HiPer ARCs, and Bay 5399/8000s (and probably
any other Annexish box with RADIUS support). This is great until you
accept routing information from one of your downstreams. One might argue
that you shouldn't peer (or listen to RIP or OSPF) from a network that'll
carry spoofed packets, but I don't think that's practicable for the
Internet of today. Not all the equipment is capable, not all the operators
are clueful, and there aren't enough incentives to change that overnight.

I won't even touch the issue of "legitimate spoofing" which rears its ugly
head in the telco return satellite and cable modem scenarios. Strict
asymmetry does make things more complicated.

regards,
  -- Robert

13

Balderdash.

That a route is *valid* doesn't mean its the best path or the one that the
router will use. It means that the path is *valid*. You're confusing
"valid" with "best".

Besides, the issue here isn't transport level circuits (where such things
matter); it is end-customer attachments, which are typically not multihomed
and even if they are, they're also typically static routed. Someone running
BGP4 with you isn't going to have this enabled on either end of that
interface.

I don't expect this to be usable on a backbone circuit. Then again, that's
not where the problems are originating.

14

Well, there is a simple knob for this:

If the Knob is turned "ON", then any packet from a source address which is
not routed to the interface it came in on is dropped.

This works for static, dynamic, and all other kinds of routing. It will
solve the problem and is trivial to implement - if any of the vendors care.

Doesn't work for asymetric networks, like satellites. But I agree, it might
be a good knob for the 80% solution. The rest of the problems must still
rely on access lists.

    --Dean

15

That a route is *valid* doesn't mean its the best path or the one that the
router will use. It means that the path is *valid*. You're confusing
"valid" with "best".

Balderdash. :slight_smile: "Strict" asymmetry, exemplified in the Hughes DirecPC
satellite service which provides no dialin pool of its own, as well as in
some telco return cable modem setups, means that all downstream traffic
will take one path and all upstream traffic the other. For that to happen,
the *only* paths which can exist are those pointing to the downstream path.
This can be addressed with not-real-soon-now technology or it can be
ignored as a special case that's somebody else's problem, but when a
customer is paying our full rates yet moving the vast majority of his
traffic through somebody else, I would prefer to keep that customer happy.

regards,
  -- Robert

16

99% of the people know that but how do you propose to relay that message
to every NOC on the Internet. THAT is the problem.

17

> 2. Routers/Gateways should be configured to drop all packets
> with invalid source addresses.
>
> The problem is us. This isn't a research network run and
> maintained by the knowledgable. This is a business. We're
> selling a product, and if we expect it to operate as
> advertised, it's up to us to educate those we sell it to.

The problem isn't us. It's cicso, and Bay, and Ascend,
and... everyone who won't put an anti-forging filter on their
border routers so we _can_ turn it on. The first time someone
co-sues cisco, it'll get fixed with 30 days.

Current recipe for anti-forging with Cisco hardware:

o Pick up CEF code (11.1(17)CC, which doesn't yet (?) exist for all
   Cisco platforms, unfortunately)

o Configure:

   !
   ip cef switch
   ! or "ip cef distributed switch" for an RSP+VIP2 based box
   !
   interface whatever
     ip verify unicast reverse-path
   !

This should (naturally) be implemented where routing is symmetric
and where a "reverse-path check" (looking up the source address in
the routing table to find the "expected" incoming interface and
checking whether the packet did indeed enter through that interface)
makes sense. If you have Ascend/Livingston or other dial-up
equipment this check should probably be implemented in the closest
up-stream router which has this capability, and definately not in a
router which could take part in asymmetric traffic patterns.

- H�vard

18

This should (naturally) be implemented where routing is symmetric
and where a "reverse-path check" (looking up the source address in
the routing table to find the "expected" incoming interface and
checking whether the packet did indeed enter through that interface)

The big question is, what do you do if most of your traffic _is_
asymetrical? I mean, a more basic check could be, "Does the network that
this packet was sourced from exist *at all*?", or "Do I have a route back
to the source network through *any* interface?"

That would cut down on a good amount of spoofing, like the idiots who
spoof from 1.1.1.1 etc.

19

> This should (naturally) be implemented where routing is symmetric
> and where a "reverse-path check" (looking up the source address in
> the routing table to find the "expected" incoming interface and
> checking whether the packet did indeed enter through that interface)

The big question is, what do you do if most of your traffic
_is_ asymetrical?

Well, in that case you can't apply this method.

It may however make sense to think of reengineering the network
so that those boxes which can't do this check sits "behind" such
a RPF-checking box.

I mean, a more basic check could be, "Does the network that
this packet was sourced from exist *at all*?", or "Do I have a
route back to the source network through *any* interface?"

That would cut down on a good amount of spoofing, like the
idiots who spoof from 1.1.1.1 etc.

It would prevent simple spoofing, yes, but that would not
eliminate the Smurf attacks since to mount a Smurf attack you
need to use the victim's address as your source address, and that
one *is* typically "valid" according to the criteria you mention
above (?).

- H�vard

20

The other extreme is that, what if you are singly-homed? Then it is
useless again.

My point is, I would guess that if you are not single-homed (in which case
this is useless), you are multi-homed, and your traffic probably isn't
symmetrical.

Therefore, I think this feature is of limited usefullness.

It would prevent simple spoofing, yes, but that would not
eliminate the Smurf attacks since to mount a Smurf attack you
need to use the victim's address as your source address, and that
one *is* typically "valid" according to the criteria you mention
above (?).

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
                  Atheism is a non-prophet organization.
       I route, therefore I am.
       Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member
               Father of the Network and Head Bottle-Washer
     Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834
Don't choose a spineless ISP! We have more backbone! http://www.nac.net
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --