smurf, the MCI-developed tracing tools (was Re: Bogus announcement)

Mailman List Mirror (Read Only)
1

Karl wrote:

However, if a forged-source data stream IS traced to one of your customers,
expect a harsh response from the general network community. This attack is
well-enough known by now that I consider anyone unable to immediately and
permanently deal with such an incident to be somewhere beneath contempt.

Well, it is going to take more education and pain, apparently.
I've got 3 national backbones upstream and they all have a hell of a
time just getting icmp-echo-reply filters in within hours of attack
onset, and usually get nowhere with tracing this to an end perp.
Granted, its a difficult, cooperative problem.

One of the better respected of them, told me that their philosophy
was to deliver all packets to me regardless of the source/type.
This corker, is the type of logic one can apparently come up with
when ones routers at Pensaulken are near fall-over.
This upstream did install the filter, after escalation, fortunately.

Until Cisco, et al, improves routers to the point where there is
low cost icmp rate-limiting (or some other better solution) we will have
a problem where backbones have to choose between expensive filtering of
ICMP-echo-replies for very long periods of time or allowing customer
connections to be randomly swamped (rendered useless) for hours by bored
13 year olds, from virtually anywhere on the net. The latter is of,
essentially, zero economic value to us, at least.

The current cost of per link filtering is apparently causing the
backbone networks major grief. It is the only current, practical solution,
as far as I can see, and yet they will do it very reluctantly because
of the cpu impact. The will to trace this attack seems to be declining also,
(less than 5 percent by one upstream account, I doubt my other
upstreams are even this organized).

We need to get router fixes in place urgently, or bite the
bullet on increased costs all around for expensive filters for long periods
in current routers, with consequently more routers required.
Backbone security teams should be reinforced as they appear to be losing
their spirit.

This problem, is disrupting the service of every isp in our region
on a frequent basis and it is getting worse week by week.

A, sometimes seen, tendency to suggest that only a few ISP's with problem
attracting users are affected by this does not recognize the breath or depth
of the problem, nor where it is heading.

Ken Leland
Monmouth Internet

2

Since source address spoofing seems to be the thing, why not bite the
bullet and put filters on from addresses on downstream clients?

It *would* start to blow out the size/complexity of the router
configurations, but if your network is of a decent size you should already
have some router config management tools written :slight_smile:

But this way, people can only spoof IPs from their own block, and not
random addresses. It would kill smurf attacks, make tracing a tad(?)
easier, etc, etc. And as I've mentioned before, not all types of floods
are ICMP attacks. If you filter ICMP, then I'll start flooding with
spoofed source addresses TCP packets with random sequence numbers and from
IPs. What, you're going to ask routers to track all the TCP connections
going through them now for validation? Erm, how many CPUs more are we
going to need..? :slight_smile:

I haven't looked at the MCI tools but my opinion is that if people start
putting filters in, you would find the instances of flooding decline. All
that needs to be done now is to discuss the best ways to do it (eg setting
up a filter on a cisco which uses AS path regexps, so you can filter per
interface on what people are announcing to you via BGP. That way, your
downstreams can only send traffic with FROM IPs that they announce, and
anyone who wants to spoof has to be speaking BGP. )

Adrian

3

Karl wrote:
> However, if a forged-source data stream IS traced to one of your customers,
> expect a harsh response from the general network community. This attack is
> well-enough known by now that I consider anyone unable to immediately and
> permanently deal with such an incident to be somewhere beneath contempt.
>

Well, it is going to take more education and pain, apparently.
I've got 3 national backbones upstream and they all have a hell of a
time just getting icmp-echo-reply filters in within hours of attack
onset, and usually get nowhere with tracing this to an end perp.
Granted, its a difficult, cooperative problem.

One of the better respected of them, told me that their philosophy
was to deliver all packets to me regardless of the source/type.
This corker, is the type of logic one can apparently come up with
when ones routers at Pensaulken are near fall-over.
This upstream did install the filter, after escalation, fortunately.

You don't want to filter ICMPs. What you want to filter is ANYTHING which
came from an invalid source address *at your entrance* from your customer
connections.

Now, for backbone<>backbone connections, this is impossible - granted.

But for end-user<>backbone connections, it is not only not impossible, it is
virtually a REQUIREMENT.

a problem where backbones have to choose between expensive filtering of
ICMP-echo-replies for very long periods of time or allowing customer
connections to be randomly swamped (rendered useless) for hours by bored
13 year olds, from virtually anywhere on the net. The latter is of,
essentially, zero economic value to us, at least.

Well, yes.

The current cost of per link filtering is apparently causing the
backbone networks major grief.

That's because people are doing it on the packet TYPE. If you filter on the
source *address*, at the ingres point to your network, it causes much less
pain.

This problem, is disrupting the service of every isp in our region
on a frequent basis and it is getting worse week by week.

Yes.

A, sometimes seen, tendency to suggest that only a few ISP's with problem
attracting users are affected by this does not recognize the breath or depth
of the problem, nor where it is heading.

Ken Leland
Monmouth Internet

Correct.

The fix is to deny inbound traffic from any connection which has an invalid
source address. You *KNOW* what the valid addresses are if you connect
someone - if I give someone 205.164.6.0/24, then anything with a source
address outside of that /24 is INVALID by definition and I should refuse
to accept it.

This is NOT difficult to do, nor is it expensive. Until it becomes a
standard part of end-user connections this problem is going to remain
extremely difficult to trace.

4

Since source address spoofing seems to be the thing, why not bite the
bullet and put filters on from addresses on downstream clients?

It *would* start to blow out the size/complexity of the router
configurations, but if your network is of a decent size you should already
have some router config management tools written :slight_smile:

But this way, people can only spoof IPs from their own block, and not
random addresses. It would kill smurf attacks, make tracing a tad(?)
easier, etc, etc. And as I've mentioned before, not all types of floods
are ICMP attacks. If you filter ICMP, then I'll start flooding with
spoofed source addresses TCP packets with random sequence numbers and from
IPs. What, you're going to ask routers to track all the TCP connections
going through them now for validation? Erm, how many CPUs more are we
going to need..? :slight_smile:

If you did this the trace would be TRIVIAL.

Then, the source network of the problem gets BGP-dropped until they kill the
source account and/or connection. This reduces smurfing to a ONE TIME
event, makes prosecution easy (anyone who thinks that such an attack,
launched on interstate facilities, against any regional or larger ISP isn't
something the Feds will want to get into is dreaming - its a slam-dunk that
the limits on damage have been exceeded) and further, raises the bar on
people who claim that they "can't fix this".

I haven't looked at the MCI tools but my opinion is that if people start
putting filters in, you would find the instances of flooding decline. All
that needs to be done now is to discuss the best ways to do it (eg setting
up a filter on a cisco which uses AS path regexps, so you can filter per
interface on what people are announcing to you via BGP. That way, your
downstreams can only send traffic with FROM IPs that they announce, and
anyone who wants to spoof has to be speaking BGP. )

Adrian

All you need to do is prevent out-of-bounds traffic from being sent into
your dedicated and dial equipment, and the problem now becomes trivial
to solve.

If it can be EASILY traced, it will stop being done. If you put these
filters in place, the Smurfer will try to use a forged address and be dismayed
when *nothing happens*. What's better, he won't KNOW that he's been
filtered, and if you log the attempts you will know that someone tried and
failed - which is a perfect reason to cancel their service.

5

This is documented in:

Network Ingress Filtering: Defeating Denial of Service Attacks
  which employ IP Source Address Spoofing;
draft-ferguson-ingress-filtering-03.txt

At the moment, we're trying to get this evntually published as
an Informational RFC.

More information can be found at:

ftp://ftp.cert.org/pub/cert_advisories/CA-97.28.Teardrop_Land

- paul

6

> are ICMP attacks. If you filter ICMP, then I'll start flooding with
> spoofed source addresses TCP packets with random sequence numbers and from
> IPs. What, you're going to ask routers to track all the TCP connections
> going through them now for validation? Erm, how many CPUs more are we
> going to need..? :slight_smile:

If you did this the trace would be TRIVIAL.

Huh?
ICMP floods vs TCP floods. Aren't they both IP or have I missed something
glaringly obvious.

Then, the source network of the problem gets BGP-dropped until they kill the
source account and/or connection. This reduces smurfing to a ONE TIME
event, makes prosecution easy (anyone who thinks that such an attack,
launched on interstate facilities, against any regional or larger ISP isn't
something the Feds will want to get into is dreaming - its a slam-dunk that
the limits on damage have been exceeded) and further, raises the bar on
people who claim that they "can't fix this".

Yep.

All you need to do is prevent out-of-bounds traffic from being sent into
your dedicated and dial equipment, and the problem now becomes trivial
to solve.

Yep.

If it can be EASILY traced, it will stop being done. If you put these
filters in place, the Smurfer will try to use a forged address and be dismayed
when *nothing happens*. What's better, he won't KNOW that he's been
filtered, and if you log the attempts you will know that someone tried and
failed - which is a perfect reason to cancel their service.

Yep.

Ok, so I agree with you completely. I thought I had made myself rather
clear in the beginning. Oh well.

I for one will be looking at integrating it into the setup here. Bar
possible router load issues, it is a good idea and means when (and if)
spoof attacks originate from our networks I can happily point to the
client rather easily. :slight_smile:

adrian

7

Huh?
ICMP floods vs TCP floods. Aren't they both IP or have I missed something
glaringly obvious.

Yes, both are independent of the network layer protocol which
operates beneath them (which in this case is IP)

The difference is that you can filter icmp seperately from tcp
to give you some sort of granularity with your acl policy. This
is important in that if you deny icmp traffic to a specific segment
of your network (or in from your serial interface for the
whole thing) you are still vulnerable to the publicized attacks
which exploit vulnerabilities inherent in TCP.

The whole point for this discussion was that you should be
a responsible network administrator and understand the trouble
you could cause the people you are connected to. Once you understand
that, you can take use the facilities that your vendor provides
to limit the damage so to speak.

BR

brad reynolds
ber@cwru.edu

8

> Huh?
> ICMP floods vs TCP floods. Aren't they both IP or have I missed something
> glaringly obvious.
>
Yes, both are independent of the network layer protocol which
operates beneath them (which in this case is IP)

The difference is that you can filter icmp seperately from tcp
to give you some sort of granularity with your acl policy. This
is important in that if you deny icmp traffic to a specific segment
of your network (or in from your serial interface for the
whole thing) you are still vulnerable to the publicized attacks
which exploit vulnerabilities inherent in TCP.

Yep.
Or just a straight out 'lets spew packet' floods.

The whole point for this discussion was that you should be
a responsible network administrator and understand the trouble
you could cause the people you are connected to. Once you understand
that, you can take use the facilities that your vendor provides
to limit the damage so to speak.

Yep.

I thought it was also just on generic spoofing/flooding and their impact
on *EVERYONE*. Disabling icmp broadcasts on the router interfaces is fine,
but later on someone will come up with something new, take advantage of
(mis)configurations of networks, start blowing people's connections away,
blah, blah, blah.

I for one am for the access lists on interfaces to stop DOWNstreams
abusing your network to flood others. Even if its just transit (no packet
blooms like in smurf). Quite a bit of the current internet infrastructure
is based upon trusting everyone who is connected to the network. And I for
one certainly dont trust everyone on the network. Tightening up on things
like this now would save a lot of pain and hassles later on.

Adrian