[nsp] known networks for broadcast ping attacks

  Here's a list of KNOWN NETWORKS that are being used to ping
flood other networks. If one of your networks is in here, FILTER
BROADCAST PINGS NOW FROM ENTERING YOUR NETWORK. YOUR NETWORK IS BEING
USED TO ATTACK OTHER NETWORKS.

      "204.71.177.255", "255.255.255.255", "207.137.200.255", "192.41.177.255",

Urm, 192.41.177.255 is the MAE-East LAN ?! Are you saying attacks are
being mounted from here or people are attacking this LAN (not
sure which is more worrying)

Alex Bligh
Xara Networks

What he's saying is that someone is mounting broadcast ping flooding
attacks with forged source addresses which make them appear to be
coming from MAE-East, among other places.

He correctly notes that this _must_ be fixed at the boundary routers.

Network operators: _please_ make sure your boundary routers do not
allow you to send packets upstream which have source addresses on them
which are not on your networks. Filters are your friend. A source
address of 127.anything is pretty uncool, too, as are broadcast
addresses... although those can be harder to figure out nowadays.

Cheers,
-- jra

  Here's a list of KNOWN NETWORKS that are being used to ping
flood other networks. If one of your networks is in here, FILTER
BROADCAST PINGS NOW FROM ENTERING YOUR NETWORK. YOUR NETWORK IS BEING
USED TO ATTACK OTHER NETWORKS.

      "204.71.177.255", "255.255.255.255", "207.137.200.255",
"192.41.177.255",

Urm, 192.41.177.255 is the MAE-East LAN ?! Are you saying attacks are
being mounted from here or people are attacking this LAN (not
sure which is more worrying)

The LAN is being used indirectly to attack another network. Pings are
spoofed as originating from the machine that is being attacked and sent to
the broadcast address on another network. This causes every machine on the
receiving network to send an ECHO_RESPONSE to the machine being attacked,
esentially creating a huge multiplying effect on a ping flood attack.

Apparently, the MAE-East LAN is one of the networks that attackers are
using to flood other hosts.

Jordyn

This is documented in:

draft-ferguson-ingress-filtering-02.txt

- paul

What he's saying is that someone is mounting broadcast ping flooding
attacks with forged source addresses which make them appear to be
coming from MAE-East, among other places.

mmmm... no. The forged source address is that of the victim. The listed
broadcast addresses are the destinations of the packets with the forged
address of the victim. The broadcast addresses are never forged.

Cheers,
-- jra

Regards,
Tripp

webmaster@http://www.netstat.net

Actually people are making it seem that the entire MAE is sending you an
echo. No one is mounting an attack from there, they are just making it
look like it is coming from there.

Alex.Bligh wrote:

Really?

Hmmm...

In any event, such filtering on the part of IAP's will solve the
problem, mostly.

Cheers,
-- jra

Time to attempt to put my other foot in my mouth.

Ought IP stack implementations not to refuse to reply to ECHO_REQUEST
packets with destination address which are broadcast addresses?

Ok, yes, I know that CIDR makes this harder, but knowing which nets
fall on non-octet boundaries is non-obvious, too, and this particular
attack wasn't trying...

.255 is _always_ a broadcast address, no?

Cheers,
-- jra

"Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> writes:

Ought IP stack implementations not to refuse to reply to ECHO_REQUEST
packets with destination address which are broadcast addresses?

Apparently some management packages search out hosts using broadcast
pings. Not the best decision IMO.

This was discussed a couple of days ago on bugtraq and I posted a
Linux patch to cause it not to answer broadcast pings.

*** How do you configure your router for that? no ip directed-broadcast.

Actually people are making it seem that the entire MAE is sending you an
echo. No one is mounting an attack from there, they are just making it
look like it is coming from there.

Well thats not entirely true. In effect the victim is indeed being
'attacked' by MAE machines on that network. Look at it like this:

evil.com -> generates packet with forged address as
(victim.com(icmp_echo)) -> destination for spoofed packet (25 .255
broadcast addresses).

From here... all 25 network's broadcast address pass the icmp with the

forged address on to all machines using that network. Each machine then
replies as:

xxx.xxx.xxx.255
abused.net.com (echo_reply) -> victim.com
abused2.net.com (echo_reply) -> victim.com
yyy.yyy.yyy.255
abused3.othernet.com (echo_reply) -> victim.com
abused4.othernet.com (echo_reply) -> victim.com

[...etc...]

Its a rather obnoxious attack, and its not exactly new. Though I do
think that it will get much worse now that smurf.c has been written and
is being passed around like candy.

The real problem I see with this particular attack is that there is
nothing short of blocking all ICMPs that 'victim.com' can do. At least
not that I am aware of.

Regards,
Tripp

webmaster@http://www.netstat.net

The real problem I see with this particular attack is that there is
nothing short of blocking all ICMPs that 'victim.com' can do. At least
not that I am aware of.

Well, I've been filtering ICMP for quite a while at my border routers,
and other than the occasional braindead sendmail configuration, and
the fact that Solaris ping can't handle the "Administratively prohibited"
return from the IOS filter rule, I've yet to see a major downside.

We have a very large quantity of people hitting our network every day.

Is there a specific reason that you can see to allow ICMP inbound to
a 'victim.com'? Or at least to more than a handful of specific
addresses? Perhaps there's a better solution with some sort of ICMP
"proxy" at or just behind the router?

Paul

Well I happen to know the writer of "smurf.c" and he is really pissed at
how his exploit for this attack has been passed around like candy, then
again, he gave it out publically on the IRC. This bug is exactly like
the one that "pepsi.c" exploited. Little kids will have their fun with
it, realize that it is dumb and that people are patching themselves
against it, and it will die.
In the meantime , I did understand how it works, just explained it a
little off :).

Netstat Webmaster wrote:

What if you supernet multiple /24's into something larger (say a /21) for
an obnoxiously large flat network. You'd have multiple hosts with
x.y.z.255 addresses that were not broadcast addresses...no?

It probably only makes sense to filter broadcast targeted traffic coming
into your network, since you can only be sure what's a broadcast address
within your own net.

Somebody recently mentioned no ip directed-broadcast. That seems to stop
incoming packets for your broadcast address...so someone then can't use
your site as a ping amplifier to attack someone else by sending ping
packets to your broadcast address claiming a source address of the
intended victim. For similar reasons, I block udp chargen requests and
replies at our GNV border router.

Well ever since this but was introduced to the outside world, I have
since modified my present Firewall (ipfwadm v2.3.0) to accomodate.

type prot source destination ports
deny icmp 0.0.0.0 0.0.0.255 any
deny icmp 0.0.0.255 0.0.0.0 any

Depending on the nature of the attack, that will handle it. I have
tested it and It has worked on my local machine.

But the best thing to do is if you find no need for a broadcast ICMP
message, simply filter it at the router.

root@gannett.com wrote:

My rule is:

deny icmp 0.0.0.0 0.0.0.0 any

With perhaps specific permits above that for devices that I find have
a legitimate need for ICMP (be it unreachables, or echo/echo reply).

I was wondering more if there were a good reason, other than for dial-up
users who may need connectivity checks, to allow any ICMP in, or ICMP to
say anything more than a terminal server's address range and certain hosts.

Hence my prior discussion on ping-mapping netblocks, and its lack of
applicability to the number of hosts on my network.

Paul

Well to allow ICMP is good for just basic pinging of you or a
traceroute. I really dont care if other people can traceroute or ping
me so i just deny those lines i mentioned before, and all ICMP as a
whole.
Until the bug passes and/or gets fixed somehow, I am going to keep those
lines.

root@gannett.com wrote:

Sorry if my previous posts confused some people [regarding ICMP]. Let me
just state right now that I wanted all of NANOG to know how 31337 I am for
knowing the author of a ping flooder. This certainly puts me in the category
of "in the know"!@#. Also, I figured I would dispell my vast knowledge and
experience regarding ICMP; since I know none of you here have any idea at
all what that is. What would you all do if I wasn't here to mentor you all?

For those that aren't lucky enough to know -- I go by MayTrickZ on IRC, and
I have t0mbs of knowledge regarding the WaR3Z underground. What I know could
fill the pages of a comic book so beware!@#

MayTrickz "Has anyone seen my IRC server?" d00d

+!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#+

Every ISP on the NET needs a WaReZ d00d, for LIGHTNING, I'm it! |
Steve Nash, snash@lightning.net MayTrickZ@IRC +

+!#$!#@$!#@$!#@$!#$!@#!@#$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@+