SMURF amplifier block list

Mailman List Mirror (Read Only)
1

The following networks and masks are banned from our network at the core due
to being smurf amplifiers.

When the folks who own these STOP THIS, we'll take them off the list.
Contact me by TELEPHONE if you want to discuss this matter or what a Smurf
is and why you should care.

I'm going to start posting the blacklist here weekly in the hopes that peer
pressure will cause people to clean up their acts. Until you DO clean up
your act, you're not transiting our network - period.

We're not going to accept this kind of vandalism and attractive nuisance any
more. If you haven't disabled directed broadcast forwarding, you are a
potential listee on this blacklist.

DO IT NOW, or risk connectivity blockades.

I urge all other network providers to block any identified smurf amplifier
that they can verify, and to post their list as well.

Only through public pressure can people be forced to CORRECTLY configure
their networks to make these attacks impossible to launch.

access-list 2 deny 128.118.0.0 0.0.255.255
access-list 2 deny 129.24.0.0 0.0.255.255
access-list 2 deny 129.111.0.0 0.0.255.255
access-list 2 deny 129.100.0.0 0.0.255.255
access-list 2 deny 128.40.0.0 0.0.255.255
access-list 2 deny 129.101.0.0 0.0.255.255
access-list 2 deny 203.64.0.0 0.0.255.255
access-list 2 deny 129.115.0.0 0.0.255.255
access-list 2 deny 203.108.225.0 0.0.0.255
access-list 2 deny 129.60.0.0 0.0.255.255
access-list 2 deny 137.79.0.0 0.0.255.255
access-list 2 deny 130.37.0.0 0.0.255.255
access-list 2 deny 130.70.0.0 0.0.255.255
access-list 2 deny 203.108.236.0 0.0.0.255
access-list 2 deny 132.169.0.0 0.0.255.255
access-list 2 deny 129.107.0.0 0.0.255.255
access-list 2 deny 129.49.0.0 0.0.255.255
access-list 2 deny 129.96.0.0 0.0.255.255
access-list 2 deny 130.65.0.0 0.0.255.255
access-list 2 deny 134.205.0.0 0.0.255.255
access-list 2 deny 129.29.0.0 0.0.255.255
access-list 2 deny 204.48.224.0 0.0.0.255
access-list 2 deny 205.177.49.0 0.0.0.255
access-list 2 deny 204.47.208.0 0.0.0.255
access-list 2 deny 204.242.172.0 0.0.0.255
access-list 2 deny 194.6.129.0 0.0.0.255
access-list 2 deny 206.31.78.0 0.0.0.255
access-list 2 deny 207.211.60.0 0.0.0.255
access-list 2 deny 206.27.242.0 0.0.0.255
access-list 2 deny 207.175.67.0 0.0.0.255

I'm sure there are more, but these are the ones blacklisted in our
network configuration right now.

2

Posting it here weekly only provides a mechanism for the littele fsckers
that smurf to gain an up to date list of sites to bounce from.

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

3

And you think they don't already HAVE the list?

Where do you think WE got it from? From people smurfing us!

The vandals ALREADY HAVE the list. I know this because we were attacked
from each of those networks at least once.

4

But posting the list of blackholed sites publicly gives the attackers a
list of sites not to bother trying to use...so they keep coming out with
new&improved versions of smurf using networks that actually work.

5

The goal is to make the number of possible sources ZERO.

If ISPs around the world refuse to forward directed broadcasts, it WILL
be zero. If a provider loses connectivity to significant parts of the
network, they'll fix their fscking routers.

I'll note that one of the worst offenders right now, and the biggest
sources, is APNIC's netblocks. There are huge, multi-T3-connected, smurf
amplifiers on some of those network numbers. You'll find that in 203.64
there are multiple high-bandwidth sources with ENABLED directed broadcasts.

Guess what? That entire /16 can't talk to us any more. I've tried talking
to APNIC with no response. I've emailed every contact I can think of -
nothing.

Now I've told them to fsck off. They can either fix the damn thing or
they can stuff connectivity to us up their behinds.

I did this to huge parts of UUNET's infrastructure a few months ago. It
*DID* get their attention, and smartly. At one time, not long back, their
entire New York POP was one huge smurf amplifier of the worst kind - multiple
MAX TNTs on 100BaseTX, all with directed broadcasts possible into their NICs.
Ouch. We saw *sustained* loads in excess of 100Mbps coming from there.
I blocked a /16, and two days later their CUSTOMERS started calling us
asking why they couldn't talk to us any more.

We told them why.

Less than a week later it magically "fixed itself", although UUNET denied
that they changed anything or that it was ever broken. Yeah, right.

At least the problem got solved.

Bluntly, I've had enough and so have my customers. Our IRC server is the
recipient of daily attacks. Our *customers* DS1s are getting hit as well.
While I can fix the IRC server problem by putting it on a Switched 100BaseTX
port, that's not really a fix -- that's just making the firehose big enough
that the jerks can't fill it.

No more Mr. Nice Guy. I don't like getting paged at 3:00 AM because some
two-bit punk got Klined off our IRC server for running clonebots and
decided to smurf us in retaliation.

My fix is to render all connectivity to and from the offending netblocks
VOID until the owners fix their routers. These folks, by the way, are NOT
clueless - they are DELIBERATELY ignoring the problem.

The folks who can source significant smurfs today are NOT Joe's T1 and Grill.
They are NATIONAL and INTERNATIONAL ISPs who damn well ought to know how to
prevent this and why they should. The guy with a T1 can't hit us hard
enough to even show up on our monitors. To make my blacklist you have to
hit me with enough bandwidth that we *see* the problem, and that means
you're at least mid-fractional-DS3 connected.

If they're permitting this kind of behavior to take place *IT IS THEIR FAULT*,
and has to be due to either deliberate lack of action or gross negligence.

I'll KEEP adding netblocks to that access group as required, and keep
posting the list. And I won't remove a single network from there until
I've VERIFIED that they can no longer be used for this kind of vandalism.

6

[...]

The folks who can source significant smurfs today are NOT Joe's T1 and Grill.
They are NATIONAL and INTERNATIONAL ISPs who damn well ought to know how to
prevent this and why they should. The guy with a T1 can't hit us hard
enough to even show up on our monitors. To make my blacklist you have to
hit me with enough bandwidth that we *see* the problem, and that means
you're at least mid-fractional-DS3 connected.

And that is a very important point here. While trying to fix every
network that can be used for smurf attacks would be a very difficult or
even futile attempt, every network that can be used for smurf attacks
isn't the issue. Yes, it is still bad, but as Karl says no matter what
they do, smurf replies originating from a T1 connected network can't take
down a moderate backbone without special effort. (ie. exploiting some
other hole other than just flooding the bandwidth)

Any sort of pressure that can be exerted to fix the well connected
networks that cause problems, including public flogging, is appropriate.
Also note that the networks that can cause real problems should have staff
capable of fixing the problem without any hassles, although should and do
are very different. The best part of all this is that the people that
refuse to take action to stop their networks being used in this manner are
wasting their own bandwidth and quite possibly a lot of money.

Karl can be quite persistent in flogging dead (or nonexistent) horses, but
I think it is a good thing he is flogging this one.

7

Hi.

May be, someone will maintain such lists? First, it allow to fix smurf
source by 'log' option in the CISCO list; second, it'll prefere some
attacks.

8

If Karl will supply us the IP address of a non-critical machine in his
network then we only need one list maintained. Anyone can then add new
networks to Karl's list simply by smurfing his non-critical machine and it
will still meet his criteria of a verified atack.

9

Sorry, you don't understand.

The worst thing in the smurf attack is not the attack itself (small IP
flood, what's it? now the hackers have not really big amlifiers at their
lists), but the fact the attacker originated source is faded usially. The
best way to found the source of such attack is to trace echo-request
packets directed to one or more smurf-amplified networks.

If some (even some) network anounce _we keep on-line list of
smurf-amplified address and control all attempts to send packets to this
networks_, do you suppose hackers would work through this network? Any
attempt to send smurf cause them to be discovered and disconnected; even
if it's only anouncement, not real control, it's enougph to prevent a lot
of hackets from the such attempts.

The only way to fight against any kind of such attacks is to be sure any
intruder should be fixed and disconnected in a few minutes. If I proclaim
(anyone who attempt to break CITYLINE.RU ISP here should be killed by the
gang of big and gloomy boys) do you think anyone in Moscow attampts to
break CITYLINE? Even if he don't believe to this anouncement - but 10%
for this to be true is enougph for hacker to be stopped.

Just this case. While we are not seing every day _XXX was catched and
disconnected due to attempt to run SMURF_ you can found any new ways to
defend yourself - no matter, they discover new ways to attack you. If
they think they can be catched - it's enougph.

Remember, this intruders use small ISP as their service providers, not
huge MCI or SPRINT.

And you even don't need the full list of such amplified addresses to open
some kind of monitoring against the smurfers.

Btw, if someone cry here _I am smurfed from XX.XX.XX.XX address, what
should you do to help him? I guess you should check (by IP accounting if
you have it; by NetFlow accounting if you have it; or close you boredom
and go home if you have not any) _are you sure the echo-request
packets to this broadcast addresses are not originated from YOUR customer_.

> May be, someone will maintain such lists? First, it allow to fix smurf
> source by 'log' option in the CISCO list; second, it'll prefere some
> attacks.

If Karl will supply us the IP address of a non-critical machine in his
network then we only need one list maintained. Anyone can then add new
networks to Karl's list simply by smurfing his non-critical machine and it
will still meet his criteria of a verified atack.

--
Michael Dillon - Internet & ISP Consulting
http://www.memra.com - E-mail: michael@memra.com

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)

10

Well, the kiddies think the IRC server is non-critical :slight_smile:

11

==>Remember, this intruders use small ISP as their service providers, not
==>huge MCI or SPRINT.

Actually, the majority of these people use compromised root accounts in
educational institutions, educational residence halls w/ Ethernet,
enterprises w/o decent firewalls, and co-location machines.

There are lists which exist of over 200-300 compromised root accounts and
access capabilities from which someone can launch an attack.

/cah

12

Yep. But the point still remains that if you can't get the traffic out of
the source network a smurf attempt doesn't work.

Those "educational" sites which allow residence hall connections to launch
this kind of thing deserve to be permanently black-holed from the Internet
until they fix things. And yes, I know this means they'll have to spend
money. Tough cookies. This is NOT an unsolvable problem (I can solve it
with a $1,000 PC running IPFW between the residence hall Ethernet and the
rest of the campus, or a few statements in a CISCO config) so people saying
its an intractable problem are lying.

Period.

13

Or, call Cisco.. press 1 and tell them you are being smurfed. They will
work with specialists and authorities to track down the attacker and rest
assured, they will be dealth with. One thing I like about Cisco, is they
don't fsck around!! They get right down to business.

14

If anyone at an educational institution tells you that send them to
UCLA http://www.math.ucla.edu/misc/smurf.html
or Simon Fraser University
http://www.cs.sfu.ca/CC/Hypermail/cmpt-471/0008.html
or the RFC archive at USC's Information Sciences Institute
ftp://ftp.isi.edu/in-notes/rfc2267.txt
or the Computer Emergency Response Team at Carnegie Mellon University
http://www.cert.org/advisories/CA-98.01.smurf.html

If those universities can handle the problem then all educational
institutions should be able to fix this.

15

I just came to realize that there is one big problem with using BGP to
blackhole these SMURF-amplifier sites.

Put really simply, if you create a BGP blackhole all you do is prevent
your packets from getting to their network - not the converse.

While being listed on a blackhole list which affects connectivity might be
enough to encourage people to set no ip directed-broadcast or equivalent
on appropriate interfaces, I'd rather see a real filter set which I can
drop the packets at my internet-facing edges. How to update the filter
set dynamically is another issue that I'd like to hear about.

Am I thinking correctly here or am I missing some convoluted BGP
configuration?

- Forrest W. Christian (forrestc@imach.com)

16

I figured this should be a new thread.

My opinion is that we need to fix some RFC's to help eliminate the SMURF
problem and other problems.

Is there a review of the Router and Host requirements RFC's in the works?
Specifically, to review those areas which could be changed to fix some of
these problems.

For example, the directed broadcast stuff should be written to basically
say that the DEFAULT must be for the directed broadcasts to be off.

The real problem here is that the RFC's say that the default must be on.
Where the BCP says that the default should be off.

I'm sure there are other discrepancies between RFC's and the BCP.
Shouldn't these be fixed? That way we have a document to point to. And,
hopefully, the hardware vendors will follow with tradition and write code
to the RFC spec.
  
- Forrest W. Christian (forrestc@imach.com)

17

My opinion is that we need to fix some RFC's to help eliminate the SMURF
problem and other problems.

Look closely. I already posted this mentioning RFC 2267

   If anyone at an educational institution tells you that send them to
   UCLA http://www.math.ucla.edu/misc/smurf.html
   or Simon Fraser University
   http://www.cs.sfu.ca/CC/Hypermail/cmpt-471/0008.html
   or the RFC archive at USC's Information Sciences Institute
   ftp://ftp.isi.edu/in-notes/rfc2267.txt
   or the Computer Emergency Response Team at Carnegie Mellon University
   http://www.cert.org/advisories/CA-98.01.smurf.html

Here's an excerpt from a message I posted to another list with a good URL:

I'm STILL lost. How am I going to "localize the effect" of my downstream -
who have not set "no ip directed broadcast" - being used as a SMURF
amplifier? As for helping them fix it, how does that relate to "DEMANDING"
the upstream fix the upstream's config?

Here is a URL with some info http://www.quadrunner.com/~chuegen/smurf.cgi

Here is what I mean.
                        -------------*-*-*-*- * - * - * * the void... :slight_smile:
                        >
FFF UUUUU OBOBOB | F = Fred's Network
FFF----UUUUU---OBOBOB-- P = Patrick's Network
FFF UUUUU OBOBOB U = Upstream provider for Fred and Patrick
          > > OB = Other Backbone provider
         PPP VVV V = Victim of the Smurf attack
         PPP VVV
         PPP VVV

Now some mean guy out there in the void decides to attack the poor victim
network by sending spoofed source packets to the broadcast address of
Fred's network. The spoofed source address is that of the victim so that
all the echo replies from the machines on Fred's network go to the
victim's network.

Now why should Patrick care? Why should he be demanding that his upstream
do something about it? Because if the Upstream does nothing, people out
there on the net may well start to block all of Upstream's address blocks.
So Patrick can demand that his upstream take action to make sure that no
SMURF amplifiers are downstream of them. Patrick has no business
relationship with Fred but both have a business relationship with the
Upstream. The Upstream could remind Fred that he must fix his routers
according to their TOS or AUP. Or they could help Fred fix his routers.
Or they could disconnect Fred. Or they could block all traffic to
?.?.?.255 in Fred's network. In fact, Upstream could regularly scan all of
its address space to find misconfigured routers and help them fix this
problem. If you have some time for code hacking maybe you could hack smurf
or fraggle to create a program that does this.

Is there a review of the Router and Host requirements RFC's in the works?
Specifically, to review those areas which could be changed to fix some of
these problems.

RFCs take a long time to change, especially standards track RFCs. But it
isn't that hard to get an informational RFC like 2267 published.

For example, the directed broadcast stuff should be written to basically
say that the DEFAULT must be for the directed broadcasts to be off.

There are no guns in the IETF. Basically the RFCs should say exactly what
they do say because that's the best consensus that people could reach.
Maybe you could convince them to revise the RFC but you'll need to fully
understand the entire scope of the protocol design, not just current
operational issues. But that's something that needs to be discussed
elsewhere. http://www.ietf.org

Might be worthwhile for someone to spend a half hour explaining the
directed broadcast issues at the next NANOG meeting?

18

In article <Pine.BSI.3.93.980412085359.7879a-100000@sidhe.memra.com>,

If Karl will supply us the IP address of a non-critical machine in his
network then we only need one list maintained. Anyone can then add new
networks to Karl's list simply by smurfing his non-critical machine and it
will still meet his criteria of a verified atack.

Careful. I could, from a well-connected machine, launch a stream of
forged ICMP echo replies from various 199.166.227.x addresses. This
would cause it to look like junction.net was the source of a smurf,
and cause them to be blocked.

Well, in the case of junction.net, there is no such forgery needed.

    ~$ host www.memra.com
    www.memra.com A 199.166.227.56
    ~$ ping 199.166.227.255
    PING 199.166.227.255 (199.166.227.255): 56 data bytes
    64 bytes from 134.87.109.226: icmp_seq=0 ttl=243 time=110.2 ms
    64 bytes from 199.166.227.41: icmp_seq=0 ttl=51 time=111.0 ms (DUP!)
    64 bytes from 199.166.227.32: icmp_seq=0 ttl=242 time=112.2 ms (DUP!)
    64 bytes from 199.166.227.54: icmp_seq=0 ttl=51 time=112.8 ms (DUP!)
    64 bytes from 199.166.227.5: icmp_seq=0 ttl=51 time=113.7 ms (DUP!)
    64 bytes from 199.166.227.27: icmp_seq=0 ttl=51 time=114.3 ms (DUP!)
    64 bytes from 199.166.227.22: icmp_seq=0 ttl=51 time=115.0 ms (DUP!)
    64 bytes from 199.166.227.1: icmp_seq=0 ttl=51 time=115.7 ms (DUP!)
    64 bytes from 199.166.227.12: icmp_seq=0 ttl=242 time=116.4 ms (DUP!)
    64 bytes from 199.166.227.19: icmp_seq=0 ttl=51 time=117.0 ms (DUP!)
    64 bytes from 199.166.227.21: icmp_seq=0 ttl=242 time=117.7 ms (DUP!)
    64 bytes from 199.166.227.28: icmp_seq=0 ttl=51 time=118.3 ms (DUP!)
    64 bytes from 199.166.227.26: icmp_seq=0 ttl=242 time=119.0 ms (DUP!)

    --- 199.166.227.255 ping statistics ---
    1 packets transmitted, 1 packets received, +12 duplicates, 0% packet loss
    round-trip min/avg/max = 110.2/114.8/119.0 ms

19

I have just fired off a message to my ISP pointing him to the instructions
for "no ip directed broadcast" so it will hopefully be fixed soon.

And I'm Cc'ing his upstream provider who probably never thought of testing
all the ?.?.?.255 addresses in their network and contacting their
downstream customers to get directed broadcast turned off. For them I'm
including the URLs

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

I sure would hate to get cut off from sending mail to Karl. :wink:

20

Anyway, does there exists some proposals about adding trace capability to
the routers? I mean - I'd like to ask the chain of routers _who does
generate the packets with the SRC address A1 and DST address A2.

Remember, the smurf problem was caused not due to amplification of the
traffic but because the intruders are not traced usially.