Subject: Internet SYN Flooding, spoofing attacks

From: Bernie Volz <[email-masked]>
Date: Fri, 11 Feb 2000 14:40:15 -0500

Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure? If every
site connected to the Internet did this, spoofing would be much more
difficult because you couldn't do it. Sure, you could spoof an address
from YOUR network, but that's all. And guess what, it would be much
easier to track and thus to shut down the intrusions should they occur.

Thus ever edge router should have filter lists that prevent it
forwarding traffic out to the Internet (ISPs network) any packet that
does not have a source address that is valid from that site.

I would hope that lots of ISPs already do this. But, perhaps not.

- Bernie Volz
  Process Software

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 11 Feb 2000 20:14:15 -0500

In message <[email-masked]>, Valdis.Kletnieks@vt
.edu writes:

> 
> Does anybody have statistics on how effective RFC2350 (Expectations
> for Computer Security Incident Response) was?  Or RFC2502 (Anti-Spam
> Recommendations for SMTP MTAs)? Or RFC2644 ( Changing the Default for
> Directed Broadcasts in Routers)?  It would seem reasonable that moving
> 2267 to BCP should have a similar effectiveness...

Well....  2267 is addressed more towards ISPs, and while there are certainly 
clueless ISPs out there, I suspect that on the average they're more clueful 
about the net than the typical end site.  (Obviously, there are exceptions in 
both categories; I did say *average*.)

		--Steve Bellovin

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 11 Feb 2000 20:14:15 -0500

--Steve Bellovin

---

From: "Anders Feder" <[email-masked]>
Date: Mon, 14 Feb 2000 22:50:19 +0100

Robert Elz <[email-masked]> wrote:
>I'm not sure there is a good analogy there.    There's no good purpose
>in sending packets with incorrect source addresses I can think of, and
>stopping the practice is the basic intent of the filters.

"In his early days at Intel, Andy Grove was approached by an employee who
suggested the company start work on a personal computer based on its chips.
Skeptical, he asked what a personal computer might do. The employee,
searching for a good example, said it could be used to store recipes. Grove
thought about the millions he'd have to spend on research, development, and
marketing, then considered the imperfect but steady quality of an
alphabetized loose-leaf binder. He finally passed on the idea and decided to
concentrate on the lucrative business of supplying chips for traffic
lights."

It is rarely very easy to see what requirements the future will bring and
particularly in this business you can't be sure what the technology of
tomorrow demands. And, agreed,  bogus source IPs _does_ at present time
look like nothing but the devils work. But in, say, 10 years a new flashy
techology could be requiring that you have the ability to stamp packets with
other IPs than your own. Unfortunately, back in year 2000, somebody put in
IP filters at all ISPs and now, 10 years after, these filters is so
integrated a part
of the ISP software that reprogramming would cost a fortune.
Also consider the size of the group of Internet users that send out packets
with incorrect source IPs. Using IP filters would be like illegalizing
coffee because a fraction of the people on the earth is allergic to
caffeine.

- Anders Feder

---

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: Vernon Schryver <[email-masked]>
Date: Tue, 15 Feb 2000 10:22:46 -0700 (MST)

> From: [email-masked]

> ...
> Well.. as soon as somebody presents us with "the real solution", we'll start
> implementing.  In the meantime, filtering is the best we know how to do.
> ...

I really wish "we" actually knew how to filter.

Just as I feared when the news broke, I'm seeing more paths where neither
traceroute nor ping work, apparently because some of "us" are so expert
that we turn off all of ICMP, and never mind intermittent blackholes from
Path MTU Discovery or diagnosing routing or other mere technical problems.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Feb 2000 12:40:42 -0700 (MST)

> From: "Michael H. Warfield" <[email-masked]>

> ...
> 	But some of us turn off ICMP except for ICMP_FRAG_NEEDED and keep
> MTU discovery alive while cutting off the ICMP food fights and script
> kiddie probes that seem to be endemic in our current mess.

Why couldn't you do as has been frequently suggested and only throttle
ICMP Echo-Request/Reply?

> 	You betcha traceroute and ping are broken (figuratively and
> literally).  Just as broken as I can make them.  You don't need to be
> tracerouting or pinging into my network and that's my choice to make.

As we all agree, what you do with your own network is only your business.
However, rest assured that if you're an ISP that breaks traceroute,
then you also break arbitrary UDP applications, and that means you
don't get any business from anyone with any sense.

> I can break them without breaking MTU discovery.  You want to diagnose
> routing or other technical problems, why aren't you contacting me?

(Hypothetically, of course) Because I do not know where the problem
is.  Without traceroute, how should I figure out to call you?  How
do I discover that you're running a transit network between here
and the other and that is trashing my packets)?

Nonsense about calling arround is exactly why traceroute was invented,
and that was back when there were a lot fewer usual suspects messing with
things.  Before traceroute, the only way to figure out what was wrong
was to call the far end and the first hop...well, besides intelligent
and laborous use of `ping` and other manual, hop-by-hop probing.
Since you turn off ICMP Echo-Requests, no one can tell.
You probably also turn of Record-Route, lest someone discover that your
routers are in the path.

> 	You cut off ICMP_ECHOREPLY and all but a tightly restricted set
> of UDP and you have just starved these DDoS zombies of the vast majority
> of their communications facility.  TCP is much easier to trace, if they
> fall back to that (I don't see how TFN2K could - it utilizes a blind

No, TCP is not more traceable because has no more IP source addresses
than UDP.  Yes, unidirectional TCP is not terribly useful for
legitimate traffic, but that also applies to UDP.

You have a such narrow view of the possibilities for a DDoS attack
that it is dangerously wrong.  If you accept any packets that cause
your systems to do any work, then I can write a distributed program
that can trash your systems, your network, or both.  All you can
do is force me increase the size of my army of zombie proxies.

If you do not accept any packets that cause your system to do any work
(including merely sending "puzzles" or checking answers), then your system
is useless.  Who would send any packets to a system that does nothing?

>                                        Blocking spoofed packets won't
> do nearly as good a job since a lot of the packets aren't spoofed.

Yes, as has been repeatedly pointed out.  
RFC 2267 filtering is good even if it is not a pancea.  The reasons
advanced for bogus IP source addresses are not compelling.

> ...
> 	They broke it's back by blocking ICMP_ECHO and ICMP_ECHOREPLY
> (fortunately, this attack was not using one of the UDP options).

It is also fortunate that it was not based on TCP packets to port 80
or UDP to or from port 53.
I'd wonder why they didn't use a distributed, very low rate per zombie
SYN attack, except I know such people are fundamentally stupid.

> ...
> 	The attackers are gaining in sophistication.  We are begining to
> see effort at "covert channels" for communications.  The tricks of
> communicating via ICMP_ECHOREPLY packets with commands in the payload
> and sending blobs of forward only commands with no reverse channel
> responses are just examples.  How long before they start sneaking past
> those defenses by sending ICMP_UNREACHABLE/ICMP_FRAG_NEEDED with
> a command data payload?

Also think about putting commands in packets to port 53 or 80.  Yes,
including TCP port 80.  If you've broken into a system, you may as well
listen to all raw packets and not just what the local TCP state machine
thinks are kosher and not only what `ping` and `traceroute` use.

Given all of that, could you remind me of why it is rational to filter
ICMP-Echo's when by your own words the bad guys don't need to use them?

As in the spam war, filtering ICMP-Echo's only advances the day whey
they use other schemes that are harder to filter.  Unlike the spam
war, it is technically easy to make bad traffic that cannot be filtered
(press releases from security outfits notwithstanding).

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Feb 2000 12:40:42 -0700 (MST)

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Feb 2000 15:06:42 -0700 (MST)

> From: "Charles E. Perkins" <[email-masked]>

> But maybe filtering is putting the cart before the horse.

I agree.

> ...
> >From that analogy, I claim that the appropriate action is to
> develop tracing systems that will help to identify a wrongdoer.
> Here is a possible design.
> - Create a router feature, able to be remotely activated, to keep
> ...

How is that different from RMON?
Or better, how does it not fit naturally into RMON?

> ...
> The basic idea then would be to trace back bad packets that
> conform to some typically innocent, but occasionally troublesome,
> profiles.  The profiles will become self-evident with experience,
> and once people know they will be caught by this traceback
> system they will think twice before spreading their crap around.

If I were building a DDoS engine today, I'd write a conventional
(Microsoft) DOS virus that does nothing except once every 3 minutes do
the equivalent of:

    echo "GET /index.html HTTP/1.0"; echo) | telnet -r $1 80

(maybe instead with a random request instead of /index.html)

After a few 1,000,000 desktops have been infected by familiar virus
vectors, the victim might notice the traffic.
How would you filter for them?  Even if you could give routers
enough processing power, what would you learn from the filtering
that you'd care to apply?

> ...
> So the costs boil down to more memory, more software, some
> pattern-matching hardware, and maintaining security relationships
> with your routing partners.

that's easy to say, but it doesn't sound likely to happen in my world.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 15 Feb 2000 15:06:42 -0700 (MST)

I agree.

---

From: Leonid Yegoshin <[email-masked]>
Date: Tue, 15 Feb 2000 16:45:38 -0800

>From: Vernon Schryver <[email-masked]>
>
>> ...

  It is possible to get more big bang in this case: virus may asks
DNS servers about some generated domain names. Algoritm to fight
negative caching effect is simple. With millions names in .com
there is a long way to keep asking.

			       - Leonid Yegoshin, LY22

---

From: Leonid Yegoshin <[email-masked]>
Date: Tue, 15 Feb 2000 16:45:38 -0800

- Leonid Yegoshin, LY22

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 16 Feb 2000 12:49:10 -0500

In message <v04220802b4d078236d2c@[171.78.30.107]>, Stephen Kent writes:
> 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).

Yes, though it isn't clear to me that most of those forged SYNs got through...
> 
> 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
> 

The problem here is that flooding attacks target the network, not the host.  
The host is thus not capable of mounting a defense -- it's not the victim, in 
some sense.

Conventional security methodology would say that the aggrieved party should do 
the authentication.  Of course, that's hard on the Internet -- in fact, we 
don't *want* people to have to authenticate themselves to the network elements 
in order to transmit.  (There are, of course, networks that do have such 
requirements.  The most common form is known as the telephone system.  I don't 
think we want to reinvent that.)  Filtering is a very coarse form of 
address-based authentication to the first outside hop; I don't see a better 
choice.

Perhaps the network can use beefed-up congestion control mechanisms to stop 
such floods.  I hope so, but it seems to be a research issue; I'd be surprised 
if such new mechanisms could be deployed sooner than 2002.  What do we do in 
the meantime?  (Trying to secure all of the myriad endpoints is even more 
hopeless than trying to get all ISPs to do proper filtering.)  Do you have any 
specific suggestions?  Seriously -- what do you recommend as a defense against 
flooding attacks?

		--Steve Bellovin

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 16 Feb 2000 14:59:55 -0500

In message <v0422080cb4d099a84d13@[171.78.30.107]>, Stephen Kent writes:
> Steve,
> 
> The AT&T experiences might be different, but at GTE-I, a SYN flood 
> was the primary attack mechanism for one major web site that we host. 
> Also, it is not at all clear that our network had a problem handling 
> the other flooded traffic (ICMP Echo Reply and UDP traffic) that was 
> sent to 3 other targets on our net, but the web hosts that were 
> targets certainly did suffer from processing the traffic.

Right.  Yahoo, though, was flooded mostly by the volume.  I worry about 
high-volume TCP garbage sent to port 80, which you can't filter.
> 
> Steve
> 
> P.S.  Nice photo and quotes in Newsweek!
> 
Thanks.

		--Steve Bellovin

---

From: Stewart Nolan <[email-masked]>
Date: Thu, 24 Feb 2000 16:19:00 -0000

Aha! I guess that means Time Travel must be discovered tomorrow, and he
really *is* Jean Paul Sartre...

> -----Original Message-----
> From: Michael Welser [mailto:[email-masked]]
> Sent: 24 February 2000 15:22
> To: Plamen Kosseff; Parkinson, Jonathan; [email-masked]; Jean
> Paul Sartre
> Cc: [email-masked]
> Subject: RE: Internet SYN Flooding, spoofing attacks
> 
> 
> Furthermore, he was posting from the future...

<snip>

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Thu, 24 Feb 2000 11:00:03 -0600 (CST)

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

Existentialists don't "die," they just go from being to nothingness.

RGF

Robert G. Ferrell, CISSP
Information Security Officer
National Business Center, US DoI
[email-masked]
------------------------------------------------------------
Nothing I have ever said should be construed as even vaguely
representing an official statement by the NBC or DoI.
------------------------------------------------------------

---

From: "Parkinson, Jonathan" <[email-masked]>
Date: Thu, 24 Feb 2000 17:30:05 -0000

Gosub with No Return ? 

-----Original Message-----
From: Robert G. Ferrell [mailto:[email-masked]]
Sent: Thursday, February 24, 2000 5:00 PM
To: [email-masked]
Subject: Re: Internet SYN Flooding, spoofing attacks

RGF

Robert G. Ferrell, CISSP