SMURF amplifier block list

Mailman List Mirror (Read Only)
1

No, IMHO, the comment stands: no matter _what_ size your network is, if
you assign host addresses with a .0 or .255 final octet, things may
break, and you deserve what you get.

Again, the likelihood that these addresses will cause problems or
experience connectivity issues is a far greater concern than the gain of
less than 1% of usable address space.

What bullshit. Am I hearing people advocating deliberately breaking
perfectly valid addresses in order to not have to tax our poor brains
for a proper solution?

Filtering out all x.x.x.255 addresses is a very bad idea. It's a
quick-and-dirty, poorly-thought-out hack. There are lots of .0 and .255
addresses in use in variously sized net blocks. We don't get to simply
say "well too bad." Especially coming from the same people who advocated
classless addressing to begin with. The byte boundaries are meaningless.
We all said so.

Dissapointed,

/cvk

2

> No, IMHO, the comment stands: no matter _what_ size your network is, if
> you assign host addresses with a .0 or .255 final octet, things may
> break, and you deserve what you get.

> Again, the likelihood that these addresses will cause problems or
> experience connectivity issues is a far greater concern than the gain of
> less than 1% of usable address space.

Watch your quoting, Charley; I said the first thing; someone else the
latter.

What bullshit. Am I hearing people advocating deliberately breaking
perfectly valid addresses in order to not have to tax our poor brains
for a proper solution?

The problem is one of leverage, Charley. If I do assign .255 to a
host, then I'm at the mercey of the entire friggin Internet. If I
_don't_... then I'm in control.

Yes, it's ugly, but (as they used to say in the navy) "that's fine
sonny, but this here's the Fleet."

Filtering out all x.x.x.255 addresses is a very bad idea. It's a
quick-and-dirty, poorly-thought-out hack. There are lots of .0 and .255
addresses in use in variously sized net blocks. We don't get to simply
say "well too bad." Especially coming from the same people who advocated
classless addressing to begin with. The byte boundaries are meaningless.
We all said so.

Welcome to the real world. Not everyone has those "you must be this
tall to ride this ride" signs on their downlinks. Sorry.

Cheers,
-- jr "it's rarely productive to argue with the weather" a

3

Then how do you effectivly protect your networks form being used as
amplifiers? Does no ip directed broadcast really work?

4

Does no ip directed broadcast really work?

Yes. It works.

And it works for whatever your particular netmask or broadcast address
happens to be, which is what's important.

The only time you shouldn't do it globally is when some other network
really needs to see broadcasts. For example, If we manage a client's
network with HP OpenView over the internet, we need to be able to send them
directed broadcasts, so that OpenView host discovery will work. Patrol
works the same way, as do other products. In this case you can't use the
"no ip directed broadcast" switch, but you can still set up access rules
which do the same thing except for the permitted network.

Bottom line is that you should protect your network from people who would
either abuse it via smurfing, or simply have no business looking for hosts
on your network. You have the tools to do it.

    --Dean

5

Yes, it works very well.

Stephen

jlixfeld@idirect.ca wrote:

6

It is important (and obvious, I hope) to realise that this does not 'fix'
smurfing; it fixes you from being a smurf amplifier.

In no way does it protect you from being smurfed.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
                  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
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

7

Yes.

http://www.quadrunner.com/~chuegen/smurf.cgi
ftp://ftp.isi.edu/in-notes/rfc2267.txt

8

Why don't use the filter

deny icmp any 0.0.0.255 255.255.255.0 echo-request

on the incoming lines? It just block 99.999% of this smurf amplifiers;
and I hardly think someone eve sence this restriction for the real PING
tests.

???

9

What about people who didn't subnet their class B on the eight bit
boundry, but made larger subnets instead? What about the class B that
doesn't appear to be subnetted at all? What about supernetted class C
networks? A trailing .255 can be a valid host.

10

Umm, I think this has already been hashed out. This is not the only netmask
on the planet, and you don't know what other networks netmasks are under
CIDR. Trying to guess the netmask just leads to breakage.

All you want to do is stop packets coming in to your broadcast address.
For example, for your network x.y.z/n (n=24) with your broadcast address
of x.y.z.255: (I presume everyone can translate between CIDR notation and
dotted decimal :wink:

deny ip any x.y.z.255 255.255.255.255

no ip directed broadcast basically puts in the same rule, but it does it
automatically by looking at the netmasks on the interfaces.

    --Dean

11

Indeed. I think that MIT uses /16 netmasks in some places, and uses numbers
like 18.43.0.77, and would expect to use 18.43.0.255.

    --Dean

12

What about people who didn't subnet their class B on the eight bit
boundry, but made larger subnets instead? What about the class B that
doesn't appear to be subnetted at all? What about supernetted class C
networks? A trailing .255 can be a valid host.

And what's worng? If they di nit subnet their B network, the tail of
address should be .255 too.

If someone have particular .255 host - OK, you should not be able to ping
it, not more. The small fee for the free-of-smurfing-from-your-network.

> Why don't use the filter
>
> deny icmp any 0.0.0.255 255.255.255.0 echo-request

Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot
of networks do not block aroadcast echo-request's; no one even know how
to trace thos 'echo-request' packets by their network... may be I am
wrong, and it's because there is _a lot of ISP_ there, and even a few af
them who do not know how to fight against SMURF compose a good backet - I
do not know.

Really; does anyone know any sucsessfull attempts to search for the
smurfer? What penalty was provided for this hackers? Does exist some
legitimate way to establish a lawsuite against them (when they'll be
located - last is the only matter of qualification for their nearest ISP,
not more).

13

I am talking about boths blocking exterior smurfers from usage your
networks as amplifier, and blocking your smurfers from sending such
packets by your network. Second task allow you to cutch any smurfer in
your own network in a 5 minutes.

Just now the only thing big ISP can do in case of SMURF is to block
ECHO_REPLY packets to some attacked networks; it results from preventing
any PING tests from this networks. Why don't sacrify some addresses
(*.255, really) from be pinged at all, but save your from be the source
or amplifier of the SMURF?

And then, if you should not block by 'log' such packets you'll have the
log records about your own smurfers withouth loosing any ICMP
capabilities at all.

Umm, I think this has already been hashed out. This is not the only netmask
on the planet, and you don't know what other networks netmasks are under
CIDR. Trying to guess the netmask just leads to breakage.

All you want to do is stop packets coming in to your broadcast address.
For example, for your network x.y.z/n (n=24) with your broadcast address
of x.y.z.255: (I presume everyone can translate between CIDR notation and
dotted decimal :wink:

deny ip any x.y.z.255 255.255.255.255

no ip directed broadcast basically puts in the same rule, but it does it
automatically by looking at the netmasks on the interfaces.

    --Dean

>Why don't use the filter
>
> deny icmp any 0.0.0.255 255.255.255.0 echo-request
>
>on the incoming lines? It just block 99.999% of this smurf amplifiers;
>and I hardly think someone eve sence this restriction for the real PING
>tests.
>
>???
>
>
>
>
>> Date: Fri, 17 Apr 1998 18:09:08 -0400
>> From: Dean Anderson <dean@av8.com>
>> To: jlixfeld@idirect.ca
>> Cc: nanog@merit.edu
>> Subject: Re: SMURF amplifier block list
>>
>> > Does no ip directed broadcast really work?
>>
>> Yes. It works.
>>
>> And it works for whatever your particular netmask or broadcast address
>> happens to be, which is what's important.
>>
>> The only time you shouldn't do it globally is when some other network
>> really needs to see broadcasts. For example, If we manage a client's
>> network with HP OpenView over the internet, we need to be able to send them
>> directed broadcasts, so that OpenView host discovery will work. Patrol
>> works the same way, as do other products. In this case you can't use the
>> "no ip directed broadcast" switch, but you can still set up access rules
>> which do the same thing except for the permitted network.
>>
>> Bottom line is that you should protect your network from people who would
>> either abuse it via smurfing, or simply have no business looking for hosts
>> on your network. You have the tools to do it.
>>
>> --Dean
>>
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Plain Aviation, Inc dean@av8.com
>> LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com
>> We Make IT Fly! (617)242-3091 x246
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>
>Aleksei Roudnev, Network Operations Center, Relcom, Moscow
>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095)
>239-10-10, N 13729 (pager)
>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
           Plain Aviation, Inc dean@av8.com
           LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com
           We Make IT Fly! (617)242-3091 x246
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

14

During an in progress attack, you probably have to take extreme measures,
but they shouldn't be generally applied. No one wants to lose addresses
that *might* be a broadcast address in some possible netmask. /24 is maybe
common, but is not the only netmask. And the people who don't use it won't
want you to break their customers networks.

    --Dean

15

During an in progress attack, you probably have to take extreme measures,

Do you remember - it's not attack against you or attack by some of your
customer's networks used as amplifier, but the attack initiated from your
own network. You never note such thing withouth some permanent
measurement.

It's why we saw this 100% helpless against the SMURF's.

but they shouldn't be generally applied. No one wants to lose addresses
that *might* be a broadcast address in some possible netmask. /24 is maybe
common, but is not the only netmask. And the people who don't use it won't
want you to break their customers networks.

    --Dean

>I am talking about boths blocking exterior smurfers from usage your
>networks as amplifier, and blocking your smurfers from sending such
>packets by your network. Second task allow you to cutch any smurfer in
>your own network in a 5 minutes.
>
>Just now the only thing big ISP can do in case of SMURF is to block
>ECHO_REPLY packets to some attacked networks; it results from preventing
>any PING tests from this networks. Why don't sacrify some addresses
>(*.255, really) from be pinged at all, but save your from be the source
>or amplifier of the SMURF?
>
>And then, if you should not block by 'log' such packets you'll have the
>log records about your own smurfers withouth loosing any ICMP
>capabilities at all.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
           Plain Aviation, Inc dean@av8.com
           LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com
           We Make IT Fly! (617)242-3091 x246
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

16

But to protect your own network, all you need is the access rule I gave.
You know your own broadcast address and netmask, and can put in a rule to
block.

You just can't block the presumed broadcast address used by other peoples
networks.

Logging attempted attacks which are blocked can't really be done with a
cisco. You need something to monitor the line coming in.

    --Dean

17

During an in progress attack, you probably have to take extreme measures,

Do you remember - it's not attack against you or attack by some of your
customer's networks used as amplifier, but the attack initiated from your
own network. You never note such thing withouth some permanent
measurement.

Oops. I misunderstood this first time round. I don't think you can easily
detect smurf initiations, because you have to guess at the broadcast
address.

I think it is much easier to detect and block forged source addresses,
which are also necessary for the hacker who is operating out of your
network.

    --Dean

18

I agree that ISPs are at the mercy of the smurfers. At MRNet we have been
fighting an internal battle to get our customers to do the right things
to block their ability to be used as a multiplier. Its not just
ignorance that keeps our customers from acting, it in some cases is their
equipment.

We have written SMURF detection software that uses cisco netflow exports
to let us know when a SMURF is going on, either inbound or outbound.
Before we had this, we didn't know how bad it was, we never saw the
majority of the attacks or where our customer nets were being used as a
multiplier. We hope to automate a block.

Cisco is working on features to help with this problem. They need to be
given time to do it right.

We have implimented a filter that blocks broadcasts on our NSP border
routers. However this list only blocks the broadcast addresses in our
CIDR blocks and on assigment boundries. It has helped alot.

We can, as network administrators, clamp down this net so hard only the
hackers would be able to use it. Blocking all .255 traffic even just
ICMP is a step too close to that. Remember the distain for routers and
hosts that made classfull assumptions when they were given an address?

19

I know that this week there was a smurf attack that was tracked to the
source. I'm not sure what will happen to him. Hopefully someone from the
NOC that caught him will let us know.

Jeremiah

Jeremiah Kristal
Senior Network Engineer
ICon CMT Corporation
jeremiah@iconnet.net
201-319-5764
x284 internal

20

If you do it on your cores as opposed to your border routes, it should
know. Your core routers probably created the aggregated B that the border
routers get from the cores and in turn advertise out. If you want to
filter at the borders (which would stop traffic from hitting your core in
the first place) that is probably the way to do it, but if you are in a
situation where you didn't subnet at the 8bit boundary, or something else,
then you may need to run with it, let the traffic hit your core, and
filter it from there.