CloudFlare helps save Wikileaks' bacon

Re:CloudFlare helps save Wikileaks' bacon by blibble on Tuesday August 14, 2012 @09:22AM (#4380757)

I've been behind a large often-targeted service for the last 10 years or so, and most of the large attacks we get are pretty easily filtered as our service is TCP (like CloudFlare), and most of the attacks we get are either ping or UDP floods, which we drop at the boundary.

a little harder is the SYN flood with spoofed addresses, how on earth can you filter those?

[ Parent | on HN ]

Re:CloudFlare helps save Wikileaks' bacon by swalberg on Tuesday August 14, 2012 @10:20AM (#4381016)

Aren't SYN-cookies [0] the traditional defence against SYN floods? The proxy, or a device in front of it, could take care of that. Only connections that complete the 3 way handshake would take up any room in the connection table.

0 - http://tools.ietf.org/html/rfc4987

[ Parent | on HN ]

Re:CloudFlare helps save Wikileaks' bacon by blibble on Tuesday August 14, 2012 @11:59AM (#4381567)

it's just the sheer amount of packets hitting our network that cause the issue, not what is inside them!

[ Parent | on HN ]

Re:CloudFlare helps save Wikileaks' bacon by Dylan16807 on Tuesday August 14, 2012 @03:11PM (#4382592)

I don't understand. Why is it simple to filter UDP but not simple to filter based on a cookie? Is the validation cpu-expensive in bulk? Do you not have the capability to filter that way at the boundary?

[ Parent | on HN ]

Re:CloudFlare helps save Wikileaks' bacon by FlukeATX on Tuesday August 14, 2012 @10:13AM (#4380981)

With this: http://www.cisco.com/en/US/docs/ios/11_3/security/configurat...

[ Parent | on HN ]