SMURF amplifier block list

Mailman List Mirror (Read Only)
21

Ok, this I may agree with. However, I contend that with appropriately
configured filters along your customer borders, that an attack wouldn't be
possible by a customer except to attack himself or another address which
matches the hole in the source address filter for the customer -> net
direction.

Hopefully those holes are as small as possible.

On another note, could someone please mention again which IOS has the cool
"drop all packets from an interface which we don't have a matching route
pointing the other direction" feature?

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

22

In article <Pine.BSF.3.96.980414033154.4326B-100000@workhorse.iMach.com>,

23

the problem with that thinking, of course, is going to crop up when you
encounter /23's and greater.

-- Aaron

24

Not often. Few people are actually supernetting within a given broadcast
domain. There's still an awful lot of hardware that doesn't work right in
that environment.

The larger problem is that subnetted /24s still are wide open. This kind of
filter won't block anything from their broadcast addresses, since they're
not the .255 address.

25

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.

Cheers,
-- jra

26

Are we really concerned about being smurfed by a /30, or even a /27?

The essential problem is backbone class-C's, especially those in NAPs
where coordination is nearly impossible. Smaller subnets tend to be in
small ISPs' or customers' networks, which don't pose a threat since they
lack the bandwidth for an effective attack.

Stephen

Karl Denninger wrote:

27

Good point.

28

Jay,

I have a B assignment. I have switched infrastructure segments
with /22 masking. Do you mean to say that the host number
range on each /22 masked segment is not continuous 1 through 1022,
but has several holes instead.? The network seems to be working
properly. I may be in big trouble!

None of my TCP/IP courses or books or Cisco CDs have prepared me for
such a surprise. Please point me to a text which will explain this.

Thanks for your help.

  JimC

29

Im kind of under the impression that we're (ok, just me, but anyone
else is welcome to jump on this bandwagon) trying to point out that
class based thinking.. or even "well, most of the net is this" thinking is
probably a bad idea. Kludges n' hacks may work most of the time, but
kludges and hacks are just that.. kludgey and hackish. Hard coded
defines, precompiled bins, etc have proven to be a less elegant method in
other areas of the computing world... why should we repeat the same kind
of mistake in the networking field? A smurf attack is just that, a smurf
attack. Wouldnt the overall goal include removing the attack possibility
in its entirety, not just a temporary solution that may solve some of the
problems, but definetly not all of them?

Assuming that most of the net is based on /24s, and that smaller subnets
are generally internal to those /24's may be a safe assumption, but once
again its probably not the best way to think about this problem (not that
I have any hints on what the best way should be, but im fairly certain
that applying a stereotypical ideology to this is "not a good thing").

just my two bits and a lot of run on sentences.

-- Aaron

30

I'm posting this answer to the list just on the off chance I've
misunderstood the world, instead of you. I'd set followups to
nodlist@nodewarrior.net, but I think the reflector would strip it off
anyway, so any further traffic on this can drop off NANOG.

IP address octets stop at .255. Period. They can't go up to "1022",
and it's probably a less than good idea to write them that way, or even
think of them that way, because no one and no software will know what
to do with them.

The assertion that Steve Sprunk and I, amongst others, were making is
that any host address that ends in .255 is probably a poor address to
assign, and yes, that means that in any network larger than a /24 (IE:
subnetted B's, or /23-/8's, to phrase it another way) that you're going
to lose more than one address per subnet.

My opinion is: this is a lot easier to live with than the possible
problems that can arise from numbering a host X.X.X.255, which are
problems that you _cannot_ correct yourself. You _can_, however,
control whether you address hosts that way or not.

Your choice.

Cheers,
-- jra

31

Aaron Beck wrote:

Im kind of under the impression that we're (ok, just me, but anyone
else is welcome to jump on this bandwagon) trying to point out that
class based thinking.. or even "well, most of the net is this" thinking is
probably a bad idea.

The fact is that a /24 is far more dangerous as a smurf amplifier than a
/30. Simple math tells you that there's 127 times as many possible
hosts hitting you.

Kludges n' hacks may work most of the time, but
kludges and hacks are just that.. kludgey and hackish. Hard coded
defines, precompiled bins, etc have proven to be a less elegant method in
other areas of the computing world... why should we repeat the same kind
of mistake in the networking field?

Who suggested putting a x.x.x.255 filter into IOS itself? An
access-list in a config is hardly hard-coding.

A smurf attack is just that, a smurf
attack. Wouldnt the overall goal include removing the attack possibility
in its entirety, not just a temporary solution that may solve some of the
problems, but definetly not all of them?

If you have a suggestion for "removing the attack possibility in its
entirety," please tell us. So far, nobody's come up with one.

In the meantime, I'd rather solve 99% of the problem and deal with the
remaining 1% than sit around arguing about "class based thinking" and
"stereotypical ideologies" in between smurf attacks.

Assuming that most of the net is based on /24s, and that smaller subnets
are generally internal to those /24's may be a safe assumption, but once
again its probably not the best way to think about this problem (not that
I have any hints on what the best way should be, but im fairly certain
that applying a stereotypical ideology to this is "not a good thing").

Look at the list of IP addresses used in any smurf attack, and they will
almost always be class C or class B broadcast addresses, usually the
address of a NAP or well-connected ISP. There's no sense targeting a
solution for a problem which doesn't exist. Solve the general case and
buy time for the more specialized ones.

just my two bits and a lot of run on sentences.

Stephen

32

You should be. If I didn't have directed broadcasts turned off on my
network, it would be a very effective smurf amplifier. Because ARIN keeps
us on a very short leash, we use the smallest subnet we can get away with
for our POPs. Some such sites are very well connected.

As far as .0 and .255 addresses go, I'm no more "asking for trouble" by
using those than I'm asking for trouble by running an IRC server. They
are completely valid addresses. Perhaps those making such comments are
better at getting IP space than we are, but we need to squeeze every IP we
possibly can into use just to provide enough addresses to our customers.

Brandon Ross Network Engineering 404-815-0770 800-719-4664
Chief Network Engineer MindSpring Enterprises, Inc info@mindspring.com
Mosher's Law of Software Engineering: Don't worry if it doesn't work
right. If everything did, you'd be out of a job.

33

Uh, folks, blocking the broadcast address will NOT help you in the case
of a smurf POUNDING ON YOU. It will ONLY prevent your customers launching
a smurf against someone ELSE. A FAR more effective means of doing THAT is
to prohibit source address forgery on your connections.

What a smurf does is this:

1) The SMURFER sends a FORGED packet to the amplifier. It is:
    source destination type
    victim-addr amplifier-broadcast ICMP ECHO

Example: 192.160.127.97 xxx.yyy.zzz.255 ICMP ECHO

The amplifier NETWORK ENTRANCE ROUTER, IF it accepts directed broadcasts,
will route this to the broadcast address of the shared media network
(ie: CSMA/CD FastEthernet).

ALL the devices on that network respond to the victim's address.

The reason this works is because (1) you don't need to be able to get
replies back from the real source (since the source is forged anyway) and
(2) the ICMP echo will be replied to (its a ping, silly).

Now, what you do is use a LARGE packet size - say, 1Kb.

So I send one packet over my ISDN line, and the amplifier sends 200 copies
of it to the victim. I can effectively multiply the bandwidth of my 128kbps
circuit 200-fold, which is TWENTY FIVE MEGABITS of bandwidth (!)

Now, since I am smart, I use an ICMP ECHO with a payload of all zeros.
STAC compresses this 1024-byte packet about 10:1, since its all one byte.
I can now source ~90Mbps from an ISDN connection! This makes even a modem
dial connection quite dangerous in that with compression and careful
selection of the payload you can source ~10-20Mbps of smurf from a MODEM.

A T1 connected person launching a smurf can burn down an OC-12 if they
can find amplifiers with enough outbound capacity.

Now, what are the problems for the person trying to prevent this from
melting their network and/or their customers?

1. If you can't actually accept and process the inbound traffic,
  you're dead. Period. This means that a small ISP, say one
  connected by a couple of T1s, can't defend against a Smurf.
  They MUST go to their upstream provider and have THEM defend
  against it.

2. If you CAN accept the traffic, then you have several defenses.
  But some of them won't work. The ones which don't work include:
  a) Blocking traffic from broadcast addresses - none of the
    smurf traffic will be from a broadcast address.
  b) Blocking OUTBOUND traffic - the problem isn't outbound,

3. The only EFFECTIVE defense is to block ALL addresses within any
  netblock which is identified as being a smurf amplifier to ANY
  inbound traffic. You want to place this filter on your INBOUND
  links from other providers and exchanges.

  That is, if you peer with someone over a HSSI line, or buy transit
  over a HSSI line, you want the filter to be:
    inter h 1/0
    ip access-group xxx in

  where the "access-group xxx" list contains things like:
    access-group 2 deny 128.0.0.0 0.0.255.255
    .....
    access-group 2 permit all

  DO NOT use extended access lists. They are wasteful in that they
  force more comparisons that are needed, and may cause you to
  degenerate into process switching at your borders (which will
  murder your CPU utilization).

4. By doing (3), you do not prevent the traffic from touching you; you
  will absorb it instead.

  To keep the traffic off you entirely, you need to have your *UPSTREAM*
  providers place the same filter on the OUTBOUND side of the interface
  that points towards your network. Good luck getting a *PEER* to do
  this - you might be able to get a *TRANSIT* provider to do it if you
  bitch loudly enough.

5. However, providing that you have the bandwidth on your interconnects
  and/or transit connections to absorb the smurfs without knocking you
  out, (3) is effective. It keeps your machines up, and it keeps your
  T1 and slower connected customers from being smurfed off the
  network.

The *ONLY* long-term fix for smurfing is to prohibit directed broadcasts, so
that amplification of the attack cannot be done. The only means available
for prohibiting anything on the Internet is "shunning", much as it is with
spammers. Therefore, the only way to force people to correctly configure
their routers so smurfs won't work is to snub them and implement (3), either
in your network or at your upstream connection's network.

34

Um, Karl? That's not what we were talking about.

What we were talking about was forbidding external connections to the
class-C broadcast addresses on a net, and why that useful process made
addressing hosts on .255 boundaries A Bad Idea.

Cheers,
-- jra

35

Reply taken off list. I was afraid of this.

Cheers,
-- jra

36

Jay,

I now understand the confusion -- You are speaking of the
dotted decimal representation of the 32 bit IP address without
regard to masking. I am speaking of the masked address which
results in a (mask length) network number part and a
(32 - mask length) host number. This means you think of
address components as octets (bytes) and I think of the
effective network number and the effective host number, the
sizes of which are determined only by the mask.

Or another way to this is that the routers and hosts do not
see the dotted notation except in the configuration dialogs.
Internal to the routing processes the effective network
number determines the routing between subnets and a broadcast
address is any address where the host number is all ones.

Another way to look at this is to say you are thinking about
IP addressing in a "classful" manner whilst I am speaking in
a "classless" manner. Believe me, the transition from classful
to classless thinking in IP addressing is not an easy thing.
None of the RFCs are simple to understand.

So, I guess I'm not in trouble after all.

Regards.

  JimC

37

So I send one packet over my ISDN line, and the amplifier sends 200 copies
of it to the victim. I can effectively multiply the bandwidth of my 128kbps
circuit 200-fold, which is TWENTY FIVE MEGABITS of bandwidth (!)

Now, since I am smart, I use an ICMP ECHO with a payload of all zeros.
STAC compresses this 1024-byte packet about 10:1, since its all one byte.
I can now source ~90Mbps from an ISDN connection! This makes even a modem
dial connection quite dangerous in that with compression and careful
selection of the payload you can source ~10-20Mbps of smurf from a MODEM.

This isn't quite as bad as it sounds, because in nearly all cases, the
*OUTGOING* bandwidth from the amplification network will be *MUCH* less
then the aggregate traffic produced by all the devices on the
amplification LAN.

So what ends up happening in most cases, is that 20-90Mpbs of traffic
slams into the router interface capable of only 1.5/3/6/9Mbps of outgoing
traffic. Still, though a modem or ISDN connection being able to summon
1.5-9Mpbs is quite a problem.

The *ONLY* long-term fix for smurfing is to prohibit directed broadcasts, so
that amplification of the attack cannot be done. The only means available

This is not the *ONLY* long-term fix.

There has been very little mention of anti-SPOOF measures in this thread
which is surprising.

Granted, blocking directed broadcasts from entering your network prevents
you from being the "mid-point" of the attack.

The fact is that the SMURF attack couldn't even get off the ground if the
ISP for the "evil d00d" validated *OUTGOING* traffic, effectively blocking
IP SPOOFing.

I would say that the scope of the IP SPOOFing problem is greater then any
other problem.

IP SPOOFing is *THE SOURCE* of all the major problems:

SYN-FLOOD
TEARDROP and variants
SMURF
What's Next???

Solutions:

Validate all traffic leaving your networks to be sure the IP source is
from one of your networks.

Everyone from the tier 1 providers on down should write that requirement
into all their connection agreements.

Further, the fact is that nearly *ALL* such attacks (attacks that use
IP-SPOOFing as a requirement) are launched from dial-up connections.

If would be relatively easy to have a *DRAMATIC* reduction in attacks if
the dialup equipment vendors would release software updates with *DEFAULT*
anti-spoof filters applied to dialup connections.

Put some pressure on your vendors, nearly all dialup ports are made by
either Lucent/Livingston, Ascend, and 3COM/USR.

I've been asking Livingston for two years for this feature.

Dax Kelson
Internet Connect, Inc.

38

This isn't quite as bad as it sounds, because in nearly all cases, the
*OUTGOING* bandwidth from the amplification network will be *MUCH* less
then the aggregate traffic produced by all the devices on the
amplification LAN.

So what ends up happening in most cases, is that 20-90Mpbs of traffic
slams into the router interface capable of only 1.5/3/6/9Mbps of outgoing
traffic. Still, though a modem or ISDN connection being able to summon
1.5-9Mpbs is quite a problem.

Well, most of the real "problem" smurf sites are DS-3 connected or better.
The little ones don't bother us.

There has been very little mention of anti-SPOOF measures in this thread
which is surprising.

Try to get people to do that.... we have, its pointless.

IP SPOOFing is *THE SOURCE* of all the major problems:

SYN-FLOOD
TEARDROP and variants
SMURF
What's Next???

Solutions:

Validate all traffic leaving your networks to be sure the IP source is
from one of your networks.

Everyone from the tier 1 providers on down should write that requirement
into all their connection agreements.

Further, the fact is that nearly *ALL* such attacks (attacks that use
IP-SPOOFing as a requirement) are launched from dial-up connections.

If would be relatively easy to have a *DRAMATIC* reduction in attacks if
the dialup equipment vendors would release software updates with *DEFAULT*
anti-spoof filters applied to dialup connections.

Put some pressure on your vendors, nearly all dialup ports are made by
either Lucent/Livingston, Ascend, and 3COM/USR.

I've been asking Livingston for two years for this feature.

Dax Kelson
Internet Connect, Inc.

Yeah, well, why not find a way to ram it down UUNET, SPRINT, MCI's, and the
rest of the national's throats first?

We already do this - its not a perfect filter, but it will only let you
transmit packets with sources that COULD possibly come from us.

39

Anyone mind sharing that conversation?

40

Oh, he carboned that? I took it off the list when it became obvious to
the most casual observer that it didn't belong here.

What he was saying was that he doesn't look at IP addresses as
AAA.BBB.CCC.DDD. He looks at them as NNNNNNN.HHH,. for whatever
decimal split is appropriate for the length of his netmask... which
must make him awfully lonely. :slight_smile:

Cheers,
-- jra