Re: Port 80 SYN flood-like behavior

[Thierry Zoller <support () sniff-em com>]

<AFAIK>

For the whole attack news see <Z%N08.16383$F01.824619 () nnrp1 ptd net> or 
http://groups.google.com/groups?selm=Z%25N08.16383%24F01.824619%40nnrp1.ptd.net&output=gplain

Quote from above : 
"Multi-tier ddos", as in whiter white.

Steve,

> What you are describing exactly fits the description of a "midpoint server" 
> participating in a new form of Distributed Denial of Service attack.

No, he said the Source IP changes over time and did/do not remain constant.

Read :
> > as another IP address starts sending its own stream of SYN packets, though 
> > occasionally more than one host will be sending traffic at a time.  Source 
> > addresses are in a variety of networks, but seem to be consistently dialup 
> > or similar type connections.

If it would have been the same "attack" then yours the source IP should remain
the same, constant, i.e in your case grc.com IP (or whatever IP you have), and by no
means have the source of a dailup, except someone is using "decoys" to hide
the real "source", or in your view "target".

Feel free to go ahead and point your browser to the securityfocus library,
you'll see that your "new attack" has been written about since many many years.
Read: spoofed source ip, probably achieved by usage of raw socks. (sic)

> We were on the receiving end of such an attack a little over one month ago.

Read : New Page being made ;)

> Briefly, the idea is that a spoofed source IP SYN flood is gently spread 
> across a LARGE number of TCP servers. Each of the many servers replies with 
> SYN/ACK packets ... aimed at the attack's intended target.

Or RST for instance if the port is closed.
Read : Spoofed Packet

> Since each 
> unacknowledged SYN/ACK will be repeated (generally three times) this 
> results in a factor-four bandwidth multiplication.

Nice maths. Not only does this depend on the stack, 
but I doubt three packets which no data part take
lot of bandwidth. (afaik, not checked, "from memory":
40 byte without TCP options)

> From the viewpoint of the attack victim, a large number of well-connected 
> Internet servers appears to be flooding them with SYN/ACK packets.

Normal behavious if the source ip is being spoofed, nothing new there too. 
IMHO there is no problem with the attack apart from bandwidth
consumption, since your stack (be it genesis or panoramix)
will send an rst packet (if allowed).

> In the case of the attack aimed at us, 202 individual Internet routers were 
> flooding us with SYN/ACK packets from the BGP port.
> I am in the process of writing up a detailed report with a detailed 
> analysis of the packet capture, but you can see what I have so far at:

Let's take another view on it, a script kiddie pointed his syn flood
script of choice towards a list of servers he previously generated and
set your IP as the source of the Attack. (i.e he spoofed you)
Now please go ahead and explain where in the world the new part of
the attack resides. 

> http://grc.com/dos/packetbounce.htm

Make sure to get this right this time, or you will create a *new* next
generation ddos attack, which results of poeple posting flames and comments
which have as topic this page. The bandwith consumption would be far
higher this time. ;)

news.grc.com (news)
Message-ID: <MPG.16abc9ee28d080b498a20f@207.71.92.194>

========================================================
....when I exchanged eMail with Verio, the attack had
 ended, but the router's COUNT of the number of attacking 
packets it had blocked for us ..... 1,072,519,399 packet blocked
========================================================

That was on 13.01.2002 the attack started 11.01.2002
1,072,000,000 packets * 40 = 42,880,000,000 bytes 

72hours  : 42,880,000,000 bytes 
1 hour   : 595,555,555 bytes
1 minute : 9,925,926 bytes
1 second : 165,432 bytes

Depends on the speed of your T1 line(s) if they can cope up with that
or not, they should.

</AFAIK>

== 
Thierry
http://www.sniff-em.com


----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com