Re: SYNCookie fallacies as an Anti-DDoS protection for VoIP

Hi,

Sorry about our website, I believe our website might be getting upgraded
at the time.

Reply you completely misunderstood, Syn Cookie is for TCP.

The same technique can be applied to any other three way handshake
protocol.

I was just commenting on the Rate Limiting and other techniques
mentioned. There are other techniques too :-)

The technique you are mentioning sniffing and responding slows down the
attacker, increases resource requirements on the attacker and comes down
to who has more horsepower. (We've evened out the odds)

Also unless the attacker is directly sitting next to the server, to
sniff responses he has to be sitting in the path of the spoofed address
s/he initially used.

While a pure SYN flood gets the server bogged down if handled without
cookie protection, requires more resources on server waiting for timeout
spawning state machines etc.


You are exactly right 100 INVITES per second bogs down Asterisk (On a
pretty powerful processor) In terms of network bandwidth this is nothing
on a GIG pipe. This is resource exhaustion on Asterisk server not the
network.

This is exactly the kind of attack I was talking about not the SYN flood
when referring to our product.


Thanks,
Satyam

-----Original Message-----
From: J. Oquendo [mailto:joquendo@xxxxxxxxxxxx] 
Sent: Friday, July 07, 2006 5:15 AM
To: Satyam Tyagi
Cc: dhiraj.2.bhuyan@xxxxxx; voipsec@xxxxxxxxxx
Subject: SYNCookie fallacies as an Anti-DDoS protection for VoIP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Firstly:

500 Internal Server Error

The server has encountered an internal error or misconfiguration
and was unable to complete your request.

If your site couldn't even get up 3 times within the last 1/2 an
hour it took to jot down these thoughts, I'd be skeptical to pursue
your product. (Hopefully your errors weren't due to a DoS attack)

Secondly:

One of the problems with SYNCookies is you're assuming that someone
is synflooding a VoIP server. What is your product going to do if I
source quench attack the VoIP server from its direct upstream link
which I can gather from a bunch of different looking glasses? ICMP
Redirects... Another issue.

Yet another problem with SYNCookies is their dependency on time.
What will your product do for someone sniffing traffic, gathering
SYNCookie information, incrementing it by one and resending.
SYNCookies *might* work under the blind spoofing realm, but you
would be assuming someone is blindly attacking you. I can't see it
working for someone determined to attack a server.

Also, a SYNcookie fix doesn't prevent flooding so again, someone
sniffing out the network can get information for resends not to
mention just guess ACK's on a fast enough connection. ACKs could be
ranDumbly and successfully generated quickly on a botnet. You could
implement ingress filtering through the stream as best as possible
but good luck getting every upstream provider to do so. May be a
start of something, but I wouldn't put all of my eggs in that
SYNCookie basket.

I was testing a tool I mentioned in my initial post that I wrote to
attack Asterisk using SIP. What I noticed was that Asterisk was
bogged down and could not function without noticeable (and I mean
extremely noticeable) latency. Now you may think this was because
the network was saturated with packets, but I had another terminal
opened and other programs worked fine.

I expect to be able to break or greatly disaffect at minimum, the
SIP protocol before this month is up and will post my findings to
those who need to know. Programs I write to test will not be
released to the public but solely to those who need to know in
hopes that if I do break it, someone can fix it.

On Thu, 06 Jul 2006 18:34:50 -0400 Satyam Tyagi <styagi@xxxxxxxxxx>
wrote:
>Hi Guys,
>
>We have a very reliable DDOS product for VOIP.
>http://www.sipera.com <http://www.sipera.com/>
>
>One of the interesting techniques is TCP SYN cookie based applied
>to
>protect against DDOS in Data Networks (we apply the same technique
>to
>VOIP protocols.)
>Another interesting technique we employ is Turing test based (Of
>course
>for VOIP)
>
>This is very different from rate limiting/dropping etc which
>result in
>lot of false+/false- based on thresholds.
>
>Also in VOIP another unique level of DDOS is stealth DDOS, you may
>want
>to check out our website to learn more
>
>Thanks,
>Satyam
perl -e 'print $i=pack(c5,(40*2),sqrt(7600),(unpack(c,Q)-3+1+3+3-
7),oct(104),10,oct(101));'
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wpwEAQECAAYFAkSuNCsACgkQVnroYexO+HILCAP/Tr/f6LCo6CRT66v6O+9ciEqclYPH
Pz6Tkq4sw1Gq3k7+aQv7gEUKPQ0LoIxj/HRHEzCywHM75Kgprpd6Rp+otED3wSEdPddO
JRpOvfrKHpLC3SYTkNcCG+U1bb8ATBWVpNIJ6LjPyPzkGdNZ/fvlnsCt65sJxs+hf4Ey
Krxl7eU=
=Q6W4
-----END PGP SIGNATURE-----




Concerned about your privacy? Instantly send FREE secure email, no
account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485