Subject: RE: Internet SYN Flooding, spoofing attacks

From: "Eliot Lear" <[email-masked]>
Date: Mon, 14 Feb 2000 19:18:10 -0800

Steve,

Let's be clear: a DOS attack is something the end point itself can do
very little to prevent, since it usually fails or succeeds upstream of
that end point.  Therefore, the end point relies on its upstream ISPs to
"do the right thing" and indeed, each of those ISPs relies on other ISPs
to similarly filter.  Each point can mitigate the damage to the point
where in sum these attacks become ineffective.  Each RPF check can
remove bad packets.  Each violated ACL can remove and LOG the bad
packets.  These are the best controls available today.  Shall we not use
them?

Also, we raise the bar from some kid injecting packets to someone
breaking into an ISP, a more difficult challenge (at least a level 3
attack on my Dungeons and Dragons guide of Hackers ;-).

----- Original Message -----
From: Stephen Kent <[email-masked]>
Newsgroups: cisco.external.ietf
Sent: Saturday, February 12, 2000 1:55 PM
Subject: Re: Internet SYN Flooding, spoofing attacks

> Paul,
>
> >
> >>When one suggests that a first tier ISP would not need to filter
> >>traffic from down stream providers, because IF they do the
filtering,
> >>then the problem will not arise via those links, one is suggesting
> >>precisely this sort of model.
> >
> >You're approaching this from the wrong perspective, in my opinion.
> >
> >There is no assumption implied that RFC2267 filtering is needed --
> >it is required. What good is it if one or two or 300 people do
> >it, and another 157,000 do not?
> >
> >Well, there is a little good, but the more people that do it, the
> >better off we all are.
> >
> >The bottom line here is that RFC2267-style filtering (or unicast
> >RPF checks, or what have you) stops spoofed source address packets
> >from being transmitted into the Internet from places they have no
> >business being originated from to begin with.
> >
> >In even the worst case, those conscientious network admins that
> >_do_ do it can say without remorse that they are doing their part,
> >and can at least be assured that DoS attacks using spoofed source
> >addresses are not being originated from their customer base.
> >
> >And this is a Bad Thing?
>
> it is a bad thing if one bases defenses on the assumption that ALL
> the access points into the Internet will perform such filtering, and
> will do it consistently.  Even if all ISPs, and down stream providers
> performed the filtering, there is no guarantee that attackers could
> not circumvent the filter controls, either through direct attack on
> the routers, or through indirect attack on the management stations
> used to configure them.  I'm just saying that while edge filtering is
> potentially useful, it would not be a good idea to assume that it
> will be effective.
>
> >
> >>Edge filtering would often be helpful, but it is not a panacea, as
> >>pointed out by others in regard to the current set of attacks, nor
is
> >>the performance impact trivial with most current routers.
> >
> >It is negligible at the edge in most cases, but you really need to
> >define "edge" a little better. In some cases, it is very low speed
> >links, in others it is an OC-12.
>
> In talking with the operations folks at GTE-I, they expressed concern
> over the performance hit for many of their edge routers, based on the
> number of subscribers involved and other configuration
> characteristics.
>
> >
> >>Because
> >>most routers are optimized for transit traffic forwarding, the
> >>ability to filter on the interface cards is limited, as I'm sure you
> >>know.
> >
> >No, I don't know that at all. _Backbone_routers_ are optimized for
> >packet forwarding -- I do know that.
>
> I would state that devices that examine IP headers and make routing
> decisions entirely on interface cards are optimized for traffic
> forwarding, vs. firewall-style devices that focus on header
> examination and ACL checking, and which typically do this by passing
> a packet through a general purpose processor, vs. in I/O interfaces.
> But, these are just generalizations.
>
> >
> >>  Also, several of the distributed DoS attacks we are seeing do
> >>not use fake source addresses from other sites, so simple filtering
> >>of the sort proposed in 2267 would not be effective in these cases.
> >
> >Again, you're missing the point.
> >
> >If attackers are limited to launching DoS attacks using traceable
> >addresses, then not only can their zombies be traced & found, but
> >so can their controller (the perpetrator himself). Of this, make no
> >mistake.
>
> Not necessarily. The traffic from a controller to the clients may be
> sufficiently offset in time as to make tracing back to the controller
> hard.  I agree that tracing to the traffic sources (or at least to
> the sites where the traffic sources are) would be easier if edge
> filtering were in place, and if it were not compromised.
>
> >
> >>Finally, I am aware of new routers for which this sort of filtering
> >>would be child's play, but they are not yet deployed.  One ought not
> >>suggest that edge filtering is not being applied simply because of
> >>laziness on the part of ISPs.
> >
> >Steve, you said that -- I didn't. I think ISP's will do what their
> >customers pay them to do.
>
> ISPs do what they perceive is appropriate to maintain and gain market
> share, consistent with their cost models and router product
> availability. Different ISPs have different ideas of how to deploy
> routers and switches to aggregate traffic, which are driven by their
> traffic models, by economics, and by vendors.
>
> Note that this is an international problem, not just a domestic one.
> Our operations folks tell me that many attacks are traceable to
> foreign sources, where the ability to ensure adherence to policies
> such as edge filtering is rather difficult.  Also, from a national
> security perspective, one would hardly rely on other countries
> enforcing such policies in their ISP domains.  That's why I think the
> best, long term approach to these problems requires a combination of
> improved host security and monitoring for attacks near the hosts
> (both appropriate measures when the hosts are servers with a vested
> interest in maintaining availability), plus rapid, automated response
> to detected attacks, and an ability to activate and adjust filters at
> all ISP interfaces, not just at subscriber interfaces.  This
> combination of measures does not rely on every ISP in the world doing
> the right thing, although it would benefit from such behavior.  It
> embodies a notion of self-protection, both at the subscriber and ISP
> levels, in support of the principle of least privilege.
>
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Feb 2000 11:03:25 -0500

Eliot,

Some of the DoS attacks we saw last week were good, old-fashioned SYN 
floods.  Hosts do have a responsibility here, more than ISPs, since 
it is quite feasible to tie up a host's pool of TCBs with a small 
number of packets, even if the attack tool does not use spoofed 
sourced addresses (or if the spoofed addresses are from a legitimate 
pool allocated to a subscriber site).

The point I have tried to make, unsuccessfully, is not that 
performing ingress filtering is bad, and thus should not be 
performed.  Rather, I am pointing out that it is a bad idea to rely 
on such filtering as a primary means of defense. There are several 
reasons for saying this:
	- not all ISPs will find it feasible to provide such filtering
	- not all ISPs are trusted to do the filtering (in the global Internet)
	- a number of DDoS attacks can be launched without using 
spoofed addresses outside of those "appropriate" to the subscriber 
site
	- some applications may legitimately make use of non-local 
addresses, as others have suggested

I have seen a long history of suggested solutions to security 
problems which are only partially effective against current forms of 
attacks, vs. providing protection against a larger class of attacks. 
I'm trying to suggest that we not follow this pattern.

Finally, there is a diminishing difference between what a script 
kiddie can do, vs. a clever attacker, because the clever attackers 
are freely distributing higher quality attack tools.  "Empowerment" 
is a hallmark of modern Internet attacks :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Feb 2000 11:03:25 -0500

Eliot,

Steve

---

From: Daniel Senie <[email-masked]>
Date: Wed, 16 Feb 2000 12:20:51 -0500

> pool allocated to a subscriber site).

And at least one of the attacks last week indeed was a smurf. Filters
would have helped in some cases and not others.

> on such filtering as a primary means of defense. There are several

Reliance on any single method will be insufficient. It will take several
methods.

>         - not all ISPs will find it feasible to provide such filtering

This needs to be addressed. Feasible due to expense of equipment,
loading, what? ISPs need to implement this now or soon. When purchasing
new gear, the ability to do filtering without affecting performance
should be on the list of features given to manufacturers.

When we first started the drafts for RFC 2267, back in 1996, concerns
were raised that equipment couldn't handle the load. The suggestion then
was the same. NEXT TIME you order equipment, make it a requirement. It
is possible to build the gear to do the filtering. If ISPs don't demand
it of their vendors, they won't get it, though.

>         - not all ISPs are trusted to do the filtering (in the global Internet)

This issue can be addressed by their upstream providers with terms of
service agreements. Will it be perfect? Unlikely.

> spoofed addresses outside of those "appropriate" to the subscriber

Which is NO reason to permit attacks which DO spoof. Filtering is going
to limit the types of attacks which can be launched, and permits
idenitification of the systems and networks where the packets come from.
It may still be necessary to chase down those sites and get action, but
at least it's possible to know WHICH SITES are the sources.

> addresses, as others have suggested

A point which is in dispute. Beyond that, operational reality is that
filtering DOES occur, and may occur somewhere neither you nor your
upstream ISP can control. To at least some extent it's useful to
understand present operational reality in choosing methodologies.

> I'm trying to suggest that we not follow this pattern.

Please suggest another course of action. To date, the IETF has spent a
considerable amount of its security mindshare on IPSec. While developing
that functionality, operational reality resulted in the deployment of
huge numbers of NAT boxes, and IPSec and NAT aren't interoperable.
Another case of operational reality and design colliding.

Ingress filtering does not provide a complete solution. Neither did the
patches to operating systems to guard against SYN flooding. By using
both of those, we limit the effectiveness of those types of attacks. I
expect we will have to add a whole suite of techniques to bring the
problems under some reasonable level of control. What is unclear is why
some think we could or should do nothing in the short term.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Daniel Senie <[email-masked]>
Date: Wed, 16 Feb 2000 12:20:51 -0500

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Feb 2000 16:16:43 -0500

Dan,

I'll suggest one course of action, but I keep emphasizing the issue 
is not one of alternates, but of recognizing the limitations of 
proposals now on the table and considering approaches that may work 
irrespective of whether everyone performs filtering.

With regard to a wide range of DoS or DDoS attacks, it seems quite 
feasible to monitor traffic to the web site to detect such attacks 
irrespective of whether source addresses are spoofed or not.  (this 
differs from IDS for broader attacks, where the recognition problem 
is much harder and the false negative rate is on the order of 20%.) 
Such monitoring can be done by a web hosting facility through purely 
passive monitoring, so as not to adversely affect the performance of 
the network used by a web hosting site.  Once an attack is detected, 
one can trigger a semi-automated response.  If one believes that the 
source addresses are not spoofed, then one can use this to direct 
filtering to selected ingress points, but the filtering can now be 
very focused, based o the characteristics of the detected DoS 
traffic. If one believes that source addressed might be spoofed, then 
one needs to activate the selective filtering on a much wider range 
of ingress points.  Since the true sources may be outside of the 
ISP's sphere of control, filtering at connections to other ISPs may 
be required in either case.

If the response is rapid enough, the attack may not have significant 
impact, which reduces the attraction of mounting such an attack in 
the first place.  One can begin disabling the filters once the 
offending traffic flows have diminished, which provides another means 
of determining the sources of traffic, as others have noted in 
previous published work on this topic.

An advantage of this style of approach is that while it can be even 
more effective if source address filtering is widespread, it also 
would work if such filtering is not completely effective, which is 
the sort of self-defense approach I prefer  It supports what the 
security community refers to as the Principle of Least Privilege.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Feb 2000 16:16:43 -0500

Dan,

Steve

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Feb 2000 08:29:03 +0000

I'm uncomfortable with the tone of some of the responses on
this thread.  I don't think there is a need for anyone to
be adversarial about this issue.

Steve Kent's point that we in the Internet community need to work 
on other better mechanisms besides RPF checks is well taken.
It is also the case that at present RPF checks provide significant
operational risk reduction for most operators (whether enterprise,
school, or ISP) and at a reasonable cost.  Nearly all of the security
mechanisms currently deployed are only providing risk reduction --
I'm not aware of any operationally deployed perfect security solution.
The trick as a community is finding cost-effective mechanisms for
reducing individual and collective risks, IMHO.

For example, @Home has found it straight forward to deploy RPF checks
in our network.  Our original motivation was merely to be a good
Internet citizen.  However, we have also found that it reduces our 
operational costs to have such filters in place (e.g. less time spent 
handling alleged abuse cases).  Other ISPs might have different situations 
leading to different conclusions.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Feb 2000 08:29:03 +0000

Ran
[email-masked]

---

From: Jean Paul Sartre <[email-masked]>
Date: Fri, 25 Feb 2000 00:41:34 +0000

> irrespective of whether everyone performs filtering.

	I am willing to write a document on the means of packet filtering and
how rules should work for different configurations and environments.
Such configurations should be very well thought and I think an official
Internet draft should be written to advice many networks and common
people on what attacks regard/not their Internet access, should they be
providers, common people browsing/surfing and so on.

> irrespective of whether source addresses are spoofed or not.

	Source-routed packets from untrusted hosts, as many of us know, have to
be dropped/ignored. I do not know if there is another kind of attack
regarding the forging of IP headers, as I didn't study ( :( ) the TCP/IP
RFCs.

> (this differs from IDS for broader attacks, where the recognition problem

	In this case, I would suggest route and interface changing in an
automatic fashion like OSPF would do (but under attacks) (correct me if
I am wrong). DoS is very dangerous on bandwidth-limited sites that
cannot choose between different routers/gateways. The interface just
gets flooded and in some cases normal traffic disappears and one must
simply disable the interface until the attack ceases.

> security community refers to as the Principle of Least Privilege.

	As attacks can come from much different sources, if a backbone can at
least log, if not ignore, strangely high traffic from a unique site (but
it cannot, again, prevent DDoS), we should at least diminish the risks
of suffering an attack.

	Cesar

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 24 Feb 2000 12:17:22 +0000 (GMT)

> how rules should work for different configurations and environments.

You can't, because you died in 1980.

hth,

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: John Stracke <[email-masked]>
Date: Thu, 24 Feb 2000 10:03:53 -0500

> You can't, because you died in 1980.

His TTL ran out.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Life is like a metaphor.                     |
[email-masked]|                                             |
\==============================================================/

---

From: Garreth Jeremiah <[email-masked]>
Date: Thu, 24 Feb 2000 17:19:00 -0500

Please excuse my incessant ramblings, but I am sure some of this makes sense.  I am
tired and thies email proves it.....most of this is in the context of DDos

Obviously the very nature of the distributed attack makes it difficult to protect
against.  Employing packet chokes, or CAR at some border router is at best reactive
and must be carefully monitored.  TOdays "farms" of servers make this possability
even less realistic as all of the requirements of all the servers behind the said
router must be taken into consideration.  Clamping UDP to 10% of the total
bandwidth may well be fine for most situations ( Web servers only doing name
resolution for example ) but then where one of those servers relies on UDP that 10%
would be quickly eradicated by "normal" traffic, disabeling the functionality of
this server.  The same may be true ( but far less likley ) for ICMP.

Lets talk ICMP for a moment...... why do you want ICMP data from the internet any
way.... or if you say you have some need, why can we not have 1 machine/device
respond for all of the others.

Surely with the processing power of today we can develop devices to pass off ICMP
processing or "abnormal packet processing" off to another, less powerfull processor
leaving the core tasks directed to the main processing unit.  If the APPP (abnormal
packet processing processor - oh my god) can server no more requests or handle no
more packets, HARD LUCK.  The core functionality of the unit is still being met and
packets outside its traffic pattern are being resirected to the other processor,
which because it is over worked is merely ignoring the packets.

as said all of this is reactive...  To my mind there are a number of proactive
solution, mostly impracticle ones..alas we can dream.  Packet choking implimented
on the end systems such that for example once more than say 30% of traffic is ICMP
it gets ignored ( this still has th problems of the traffic is still being sent,
but as bandwith is used up datagrams are the first to be dropped from the route
such as ICMP and UDP )  this would of course have its own overhead of continually
analysing traffic in each endsystem.

An alternative is one that I do not like as it destroys the essence of "you can do
anything on the internet".  This would be to distribute the defence effort.....
begin looking for the signs of communication between the clients/masters
masters/daemons but in reality, if this could be done then we would have allready
irradicated the common "rpc" issues that allow DDoS daemons to become established.

Oh well life is like a box of sticky brown things that make you fat like me....but
can apparently be good for the heart. G.