Smurfing

Don't these answers answer a different question? Isn't the question how to
filter *outbound* attacks, not inbound ones? Filtering the inbound ones is
pretty easy on a Bay or anything with filters (drop packets bound for the
broadcast addresses). Filtering outbound is another story, especially with
CIDR. I would like to set up my routers to make sure I'm protecting as much
of the 'net as possible from attempts by my customers to do evil. However,
it's not clear to me how to do that. Does "no ip directed-broadcast" somehow
filter the *outbound* attacks or just the inbound ones?

I don't think its possible since only the local router has exact
information on the broadcast addresses it supports.

Now on something like Mae-East, what is the deal if someone pings
192.41.177.255?

-Deepak.

Hi,

getting Smurfing "under control" takes two things:

o All router administrators on the immediately reachable
   Internet needs to turn off directed broadcasts on their router
   interfaces. It's conceivable that "a significant portion of
   all" would do as well, but the magnitude of this problem
   boggles the mind. First of all, we'd need to distribute the
   appropriate amount of clue to all the corners of the net where
   this needs to happen. Maybe, just maybe, we'll get there
   sometime (I'm an optimist!).

o Making sure source IP address spoofing isn't as easily done as
   it is now. Also an easy one, right? :wink:

   Anyone have any idea where most of the attacks originate:
   dial-up ports or from folks more directly connected to the
   net? (I'd bet on a happy mix :wink:

   Equipment providers can offer some help here in offering an
   effective and efficient knob which can do the equivalent of
   "RPF"ing on unicast traffic (if you don't have a route back to
   the source and the route doesn't point to the incoming
   interface for the packet, drop it on the floor). Obviously,
   this assumes symmetric traffic patterns, which are typical at
   the edges of the network but not quite so typical in our/your
   modern backbone networks.

o While we struggle with the above two, at least some service
   providers need to become more responsive in tracking these
   sort of events back to their real source. No names mentioned,
   none forgotten.

o Lastly, I think that better tools are needed to track this
   sort of attacks back to their source (?).

I'm not saying these battles should not be fought; far from it,
but it's probably going to take a while before any of these can
have any significant effect on the problem.

- H�vard

o All router administrators on the immediately reachable
   Internet needs to turn off directed broadcasts on their router
   interfaces. It's conceivable that "a significant portion of
   all" would do as well, but the magnitude of this problem
   boggles the mind. First of all, we'd need to distribute the
   appropriate amount of clue to all the corners of the net where
   this needs to happen. Maybe, just maybe, we'll get there
   sometime (I'm an optimist!).

why should this not have become the default mode for all vendor diustributed
router code?

randy

*> o All router administrators on the immediately reachable
*> Internet needs to turn off directed broadcasts on their router
*> interfaces. It's conceivable that "a significant portion of
*> all" would do as well, but the magnitude of this problem
*> boggles the mind. First of all, we'd need to distribute the
*> appropriate amount of clue to all the corners of the net where
*> this needs to happen. Maybe, just maybe, we'll get there
*> sometime (I'm an optimist!).

Because routers used by regular companies on their intranets generally need
to propogate directed broadcasts so that protocols and software that use
directed broadcasts in a subnetted environment will work properly. Its only
at the borders of other companies (such as ISP's) that directed broadcasts
have to be turned off.

Even ISP's that use things like HPOV SNMP host discovery internally need to
permit internal directed broadcasts. But they shouldn't go outside your
network, and you probably don't want them coming in from the outside to
your internal network.

It would be a bad default, since the less experienced net-admin at a
private company might not understand why broadcasts don't work, whilst the
more sophisticated net-admins supposedly found at ISP's and NSP's know
about these things, and usually have some tools to quickly configure
routers in cookie-cutter fashion, making the defaults unnecessary :wink:

    --Dean

==>> o All router administrators on the immediately reachable
==>> Internet needs to turn off directed broadcasts on their router
==>> interfaces. It's conceivable that "a significant portion of
==>> all" would do as well, but the magnitude of this problem
==>> boggles the mind. First of all, we'd need to distribute the
==>> appropriate amount of clue to all the corners of the net where
==>> this needs to happen. Maybe, just maybe, we'll get there
==>> sometime (I'm an optimist!).
==>
==>why should this not have become the default mode for all vendor
==>diustributed router code?

Because the routing RFC[1] states:

==>Don't these answers answer a different question? Isn't the question how to
==>filter *outbound* attacks, not inbound ones? Filtering the inbound ones is
==>pretty easy on a Bay or anything with filters (drop packets bound for the
==>broadcast addresses). Filtering outbound is another story, especially with
==>CIDR. I would like to set up my routers to make sure I'm protecting as much
==>of the 'net as possible from attempts by my customers to do evil. However,
==>it's not clear to me how to do that. Does "no ip directed-broadcast" somehow
==>filter the *outbound* attacks or just the inbound ones?

"no ip directed-broadcast" keeps you from being one of the intermediaries
in the attack (traffic multiplier). It prevents a perpetrator from being
able to multiply his traffic toward the victim, which is what makes smurf
so dangerous.

Outbound spoof filtering fixes more than just the smurf attack, and is
what everyone *should* be doing to protect against customers spoofing.

For now, you can place outbound ACL's on your interfaces.

Some folks have reported that functionality is currently being tested for
a unicast RPF check for Cisco IOS. This feature will (on a per interface
basis) allow you to specify that packets coming in on an interface must
follow that interface to get back to the host. Note that this feature
will not work everywhere (multihomed/first-exit environments), but will
provide protection against spoofing.

/cah

A common theme seems to be cable modems -- I fear that some cable
companies have more money than brains and provide their users with huge
bandwidth and no IP spoof checking...

It seems to me that the only way to stop IP spoofing is to implement a
small amount of regulation (ugly word, I know). If MCI, Sprint, and all
other larger players simply stated that one cannot connect to their
network without a router audit of some kind, most of these problems would
go away. If I were Joe ISP and I was told that my carrier is allowed to,
at any time, audit my router config, and shut me down if I didn't have the
rules set right, I would be pretty sure to make sure I got things right.

Just a thought...

>> o All router administrators on the immediately reachable
>> Internet needs to turn off directed broadcasts on their router
>> interfaces. It's conceivable that "a significant portion of
>> all" would do as well, but the magnitude of this problem
>> boggles the mind. First of all, we'd need to distribute the
>> appropriate amount of clue to all the corners of the net where
>> this needs to happen. Maybe, just maybe, we'll get there
>> sometime (I'm an optimist!).
>
>why should this not have become the default mode for all vendor diustributed
>router code?

Because routers used by regular companies on their intranets generally need
to propogate directed broadcasts so that protocols and software that use
directed broadcasts in a subnetted environment will work properly. Its only
at the borders of other companies (such as ISP's) that directed broadcasts
have to be turned off.

If the ICMP packet is permitted in to the internal network then it
doesn't matter where the network is, only that it have sufficient
bandwidth to generate the necessary traffic out to the border (from
the smurfer's POV). This is why it needs to be turned off on all
LAN segments (assuming it isn't used for other things).

Even ISP's that use things like HPOV SNMP host discovery internally need to
permit internal directed broadcasts. But they shouldn't go outside your
network, and you probably don't want them coming in from the outside to
your internal network.

How often is SNMP host discovery done? Can't HPOV be directed to just
discover on a specific network?

bye,
ken emery

Oh, _obviously_, Dean. :slight_smile:

Cheers,
-- jra

While I would argue that directed broadcasts should be off by default, I
recently read RFC 1812 (Requirements for IP Version 4 routers) and found
the following in section 4.2.2.11:

(d) { <Network-prefix>, -1 }

         Directed Broadcast - a broadcast directed to the specified
         network prefix. It MUST NOT be used as a source address. A
         router MAY originate Network Directed Broadcast packets. A
         router MUST receive Network Directed Broadcast packets; however
         a router MAY have a configuration option to prevent reception
         of these packets. Such an option MUST default to allowing
         reception.

Until the RFC gets modified router vendors will probably allow reception
of directed broadcasts by default to remain compliant with RFC 1812.

David.Schmidt@ior.com Internet Ventures, Inc. (509)622-2878 x238
Spokane, Washington http://www.perki.net/ (509)622-2872 (fax)

Nice idea...but at least some of the bigger providers are already spread
so thin they can't monitor their own routers. When are they going to find
the time to read router configs for their customers' routers? They'd have
to hire more staff for this...and they'd have to actually pay more than
minimum wage.

If the ICMP packet is permitted in to the internal network then it
doesn't matter where the network is, only that it have sufficient
bandwidth to generate the necessary traffic out to the border (from
the smurfer's POV). This is why it needs to be turned off on all
LAN segments (assuming it isn't used for other things).

If you enable broadcast forwarding on a cisco, thats true. But you should
have access filters in place at your borders to prevent directed broadcasts
to your networks and subnets.

Internally, directed broadcasts are (often) used. The main thing is to
prevent others from using them, either unnecessarilly, or maliciously.

How often is SNMP host discovery done?

It's configurable. I think the default shipped is every 15 minutes. I
usually turn it down to once a day.

Can't HPOV be directed to just
discover on a specific network?

It can, and in fact it should be. But if you have turned off forwarding
directed broadcasts on that network, it won't work.

    --Dean