Guillaume FORTAINE wrote:

Misters,

No comments ?

http://docs.google.com/viewer?url=http://www.loud-fat-bloke.co.uk/obeseus2.p...

http://docs.google.com/viewer?url=http://www.parliament.uk/documents/upload/...

http://barometer.interoute.com/barom_main.php

The paper is pretty high level, and the software doesn't appear to be available for download. So it's kinda theoretical.

At first blush, I would say it's an interesting idea but won't actually resolve anything of the scariest DDOS attacks we've seen. (Unless I've missed something obvious about your doodle). The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring. You *can* punt those requests that are all identical to caches/proxies/IDS/Arbor/what have you and give higher priority to requests that show some differences from them... but you are still mostly at the mercy of serving them unless you *can* learn something about the originator/flow/pattern -- which might get you into a state problem. Where this might work is if you are a large network that only serves one sort of customer and you'd rather block rogue behavior than serve it (at the risk of upsetting your 1% type customers). This would work for that. Probably good at stomping torrents and other things as well. Best, Deepak

-----Original Message----- From: Guillaume FORTAINE [mailto:gfortaine@live.com] Sent: Monday, March 15, 2010 2:57 AM To: nanog@nanog.org Subject: Re: OBESEUS - A new type of DDOS protector

Dear Mister Wyble,

Thank you for your reply.

On 03/15/2010 07:00 AM, Charles N Wyble wrote:

...

The paper is pretty high level, and the software doesn't appear to be available for download.

http://www.loud-fat-bloke.co.uk/obeseus.html

http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz

...

So it's kinda theoretical.

"We have it running parallel with a commercial product and it detects the following attacks ▪ SYN floods ▪ RST floods ▪ ICMP floods ▪ General UDP floods ▪ General TCP floods"

Best Regards,

Guillaume FORTAINE

On Mon, Mar 15, 2010 at 9:44 PM, Guillaume FORTAINE <gfortaine@live.com> wrote:

Dear Mister Jain,

Thank you for your reply.

You are speaking about EDoS (Economic Denial of Sustainability). Please see the following article :

http://www.rationalsurvivability.com/blog/?s=EDos

Consider a new take on an old problem based on ecommerce: Click-fraud. I

actually deepak was just saying that if you diffuse the botnet enough you don't have to send more traffic from individual nodes than would be normally expected. In total they swamp the end service (potentially). There wasn't any discussion of clickfraud in his note.

That's right M.Fortaine .. and your model does not, as yet, appear to address what you term as EDoS and what the general security community calls "DDoS" On Tue, Mar 16, 2010 at 7:29 AM, Guillaume FORTAINE <gfortaine@live.com> wrote:

From my point of view, it seems similar to the EDoS concept :

http://www.rationalsurvivability.com/blog/?s=EDos

"EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize distributed attack sources as well as single entities, but works by making legitimate web requests at volumes that may appear to be “normal” but are done so to drive compute, network, and storage utility billings in a cloud model abnormally high."

-- Suresh Ramasubramanian (ops.lists@gmail.com)

I got your point. What I was saying is that what he calls EDoS (and I'm sure he'll say obliterating infrastructure is the ultimate form of an economic dos) is just what goes on ... You may or may not be able to overload the AWS infrastructure by too many queries but you sure as hell will blow the application out if that ddos isnt filtered .. edos again. On Tue, Mar 16, 2010 at 7:35 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

eh.. I guess I'm splitting hairs. the goal of 100k bots sending 1 query per second to a service that you know can only sustain 50k queries/second is.. not to economically Dos someone, it's to obliterate their service infrastructure.

Sure, you could ALSO target something hosted (for instance) at Amazon-AWS and increase costs by making lots and lots and lots of queries, but that wasn't the point of what Deepak wrote, nor what i corrected.

-- Suresh Ramasubramanian (ops.lists@gmail.com)

If only there were other security experts on this list with a proven ability to make this thread even more absurd. On 16/03/2010, at 4:47 PM, Guillaume FORTAINE wrote:

Misters,

Thank you for your reply.

1) First of all, I am absolutely not related to the Obeseus project. From my point of view, the interesting things were that :

a) This project was unknown.

http://www.google.com/search?q="obeseus"+"ddos"&btnG=Search&hl=en&esrch=FT1&sa=2

b) This project comes from an ISP.

http://www.loud-fat-bloke.co.uk/links.html

c) Its code is Open Source.

http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz

My conclusion is that I give far more credit to Obeseus than to Arbor Networks. By the way, I am surprised that this post didn't generate more interest given the uninteresting babble that I have been forced to read in the past on the NANOG mailing-list from the so-called "experts".

2) EDoS is a "DDoS 2.0"

DDoS is about malicious traffic.

EDoS is malicious traffic engineered to look like legitimate one.

However, the goal is the same : "to obliterate the service infrastructure", to quote Mister Morrow.

3) I do my homeworks something that doesn't seem to be the case for a lot of people on this mailing-list.

a) I would want to highlight the post of Tom Sands, Chief Network Engineer, Rackspace Hosting entitled "DDoS mitigation recommendations" [1].

-It seems evidence that he tried the Arbor solution so the three "Arbor++" mails don't make sense.

-About the fourth one :

"Sorry but RTFM

http://mailman.nanog.org/pipermail/nanog/2010-January/thread.html#16675

Best regards"

Hey kid, Tom Sands subscribed nearly a decade ago on the NANOG mailing-list. When you went out of school, he was already dealing with DoS concerns :

http://www.mcabee.org/lists/nanog/Jan-02/msg00177.html

b) I am really asking myself how much credit I could give to a spam expert, Suresh Ramasubramanian, about a DDoS related post [2].

c) Mister Morrow, even if you are a Network Security engineer at Google [3] (morrowc@google.com) :

-You didn't provide any useful feedback on Obeseus.

-You totally missed the point on my other mails.

This is definitely disappointing.

Is this mailing-list a joke ?

Especially, where is Roland Dobbins ?

Best Regards,

Guillaume FORTAINE

[1] http://mailman.nanog.org/pipermail/nanog/2010-January/016675.html [2] http://www.hserus.net/ [3] http://www.linkedin.com/in/morrowc

On 03/16/2010 03:11 AM, Suresh Ramasubramanian wrote:

...

I got your point. What I was saying is that what he calls EDoS (and I'm sure he'll say obliterating infrastructure is the ultimate form of an economic dos) is just what goes on ...

You may or may not be able to overload the AWS infrastructure by too many queries but you sure as hell will blow the application out if that ddos isnt filtered .. edos again.

On Tue, Mar 16, 2010 at 7:35 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

...

eh.. I guess I'm splitting hairs. the goal of 100k bots sending 1 query per second to a service that you know can only sustain 50k queries/second is.. not to economically Dos someone, it's to obliterate their service infrastructure.

Sure, you could ALSO target something hosted (for instance) at Amazon-AWS and increase costs by making lots and lots and lots of queries, but that wasn't the point of what Deepak wrote, nor what i corrected.

!DSPAM:22,4b9effc213882481555555!

Dear Mister Dobbins, Thank you for your reply. What do you think about Obeseus ? I look forward to your answer, Best Regards, Guillaume FORTAINE On 03/16/2010 05:16 AM, Dobbins, Roland wrote:

On Mar 16, 2010, at 10:47 AM, Guillaume FORTAINE wrote:

...

Especially, where is Roland Dobbins ?

At your service.

;>

----------------------------------------------------------------------- Roland Dobbins<rdobbins@arbor.net> //<http://www.arbornetworks.com>

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Dear Mister Dobbins, Thank you for your reply.

Flow telemetry has demonstrated its extraordinary utility to network operators worldwide over the last decade, and continued advances such as Cisco's Flexible NetFlow and the IETF IPFIX/PSAMP effort signify that this is the broad consensus of the operational community.

What about Argus ? [1] http://qosient.com/argus/

Layer-7 attacks against various types of services/apps can achieve significant amplification effects and disproportionate impact, are increasing in frequency and impact, and therefore must be addressed by any operationally viable solution in this space.

https://www.dpacket.org/

I believe that an effective and operationally useful open-source solution for basic DDoS detection/classification/traceback/mitigation can be implemented using existing widely-used and -understood tools/techniques as described here:

<http://mailman.nanog.org/pipermail/nanog/2010-January/016747.html>

Me and my partners are working on a Flow Based Security Awareness Framework for High-Speed Networks. http://docs.google.com/viewer?url=http://www.vabo.cz/spi/2009/presentations/... For a demo : http://demo.cognitivesecurity.cz/ I look forward to your answer, Best Regards, Guillaume FORTAINE [1] https://tools.netsa.cert.org/wiki/download/attachments/10027010/Bullard_IntroductionToArgus.pdf?version=1&modificationDate=1263221338000

Dear Mister Dobbins, Thank you for your reply.

Argus is OK, but I believe that it mainly relies upon packet capture - it does now support NetFlow v5, and v9 support as well as support for Juniper flow telemetry and others is supposed to be coming.

Argus is a superset of Netflow [1]. It's a *better* Netflow : http://docs.google.com/viewer?url=http://www.cert.org/flocon/2009/presentati...

I've personally not played with Argus and NetFlow; nfdump/nfsen is a useful open-source NetFlow collection/analysis system.

There is also Psyche from Pontetec that is a better nfsen : http://psyche.pontetec.com/

...

Me and my partners are working on a Flow Based Security Awareness Framework for High-Speed Networks.

http://docs.google.com/viewer?url=http://www.vabo.cz/spi/2009/presentations/...

For a demo :

http://demo.cognitivesecurity.cz/

It's always good to see folks motivated to work on solutions they believe will benefit the community at large.

Thank you. The question is : Who are the people interested in our work ? Best Regards, Guillaume FORTAINE [1] http://www.qosient.com/argus/argusnetflow.htm

On Tue, 2010-03-16 at 04:47 +0100, Guillaume FORTAINE wrote:

c) Its code is Open Source.

http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz

My conclusion is that I give far more credit to Obeseus than to Arbor Networks.

Hmm, the "hey! it's open source!" factor doesn't hold much sway in the network world, no-one will be amazed at that. Many observers are surprised at the amount of free software employed by ISPs and the like, but it's certainly no news to insiders. Cisco, Arbor and others all have products based on Linux kernels and BSDs, as only two examples. Sure, the "products" aren't open sourced, but in a world where moving packets is the main business - what works, goes. (I'm a Beastie/Puffy/Tux proponent myself, so I'm not trying to criticise your approach, just a comment on addressing the list. Most of us here are either one of the following here: 1/ Open-Source users/converts 2/ FOSS users/converts (not the same thing as #1) 3/ "Originals" (eg: Vixie et.al.) 4/ BSD-style-license industrial users (some very big names involved, quietly, in this category) 5/ Quagga/Bird/OpenBGPd users 6/ MS-Windows-only people who happily SSH into various items of hardware running various operating systems all day long without worrying about it. 7/ a combination of all of the above and more At the end of the day, I say it again - what works, goes

Especially, where is Roland Dobbins ?

hey, careful, if you're looking for a fight we'll let Randy out of his box, and you don't want to get that ;) It's mainly (ie: intended to be...lol) an operational list, not a theoretical discussion list. It's always good to have a different point of view here, just don't bait the dogs so hard =8^} Gord -- rockin ze NOC ( mit MOC in a shell )

Dear Mister Jain, Thank you for your reply. Please see the following article from Barry Greene : http://www.senki.org/?p=623 DDOS Trends Changing – More Effective Attack Classes. I will giving an interview today that the industry has done a poor job in communicating the changes in Denial of Service (DOS) attacks. CERT-FI’s release of the “Sockstress” details yesterday has a few people confused. Outpost24 discovered some new TCP state abuse technique which can cause a range of issue on a TCP stack (see CERT-FI’s release details). It is a serious issue. But, if it is serious, why is there not a lot of attention on this attack vector. The answer is simple. There is a lot of attention – TCP Connection Oriented State abuse is real. There is a real TCP state DOS threat. It is just not generally visible to the public. In fact, the TCP Connection Oriented State attacks more real than the general IT industry realizes. Why? Cyber-Criminal Market Dynamics! Go back to 2006. In those days, a cyber-criminal would plan a extortion attack. “Pay me big buck by this date or I’m going to DOS you to oblivion.” To demonstrate the threat is real, the cyber-criminal would provide a demonstration, whacking the victim with a TCP SYN flood which would overwhelm the site’s ability to respond via TCP (TCP table s full). The TCP flood would take up all the target’s bandwidth to the Internet. To achieve this, the cyber-criminal would need to put more bandwidth at the target then the bandwidth available to the target (i.e. throw 1 Gbps of attack traffic down a 155 Mbps link). This overload would trigger a second set of events. The “demonstration” would send way too many TCP SYNs, filling up the bandwidth to the victim, back pressuring on the Service Provider’s PE router, and creating collateral damage on the SP’s other customers. This collateral damage wakes up the sleeping giant – with a SP’s SLA getting violated and forcing them to act. Now the cyber-criminal is dealing with their “target” and the target’s SP. The SP can and will throw want ever resource available to insure their SLAs to the range of the customers to not get violated. The victim gets help (or gets offered a ‘clean pipes’ service). In the end, the cyber-criminal’s pay off of “big bucks” is disrupted. All because their TCP State attack threw to many packets at the target. What they need was a better tool. Fast forward to July 2009. A new BOTnet starts an attack on a range of US Government, commercial and Korean sites. The press goes wild with “North Korean cyber-warefare.” What is missed is that this attack is effective and not choking up bandwidth. This July 2009 attack is typical of what is seen today – a crafted TCP Connection Oriented State attack which is not a SYN flood. The malware in the BOTNET is designed to use a variety of TCP techniques – some simple (open a TCP connection and tickle it to keep it alive) and TCP abusive (attacks highlighted by Outpost24, Phrack, and others). All these techniques are designed to fill up a target’s “state table.” This state table can be a server (web, voice, application), a firewall, a load balancer, a reverse cache or any other device which terminates TCP State. The core principle of these sort of TCP State attack are to keep TCP connections open and alive. The more TCP connections you can keep open, greater the chance you will fill up the TCP state table – allowing no new TCP connection into the system – completing the DOS attack. The advantage with this class of TCP State attacks is that you do not need a lot of bandwidth. TCP SYN floods FIFO (First In First Out) the TCP state table, which is why it requires a lot of packets. Connection oriented TCP state attacks just need to open the session and keep the session open, needing far fewer packets. Far fewer packets mean you are not flooding the target’s links to the Internet. Not flooding the links to the Internet means no collateral damage on the SP’s infrastructure or customers. The SP’s SLA is not violated, hence, the SP is not motivated to jump into the middle of the attack. In essence, the cyber-criminal’s goal is complete. They can now threaten the target with “Pay me big buck by this date or I’m going to DOS you to oblivion” without the big SP getting into the way of the “big bucks.” The obvious next question is “if this is so easy, why isn’t it happening more often?” We’ll get to that in the next article. There are a range of factors – some economic, some technology, and some based on the dialectic with the community which mitigates wide spread extortion, retribution, and vindictive TCP Connection Oriented State Attacks from being more widely used. For now, anyone who is really interested in this topic should download and read Security Assessment of the Transmission Control Protocol (TCP) by Fernando Gont and sponsored by the UK CPNI (Centre for the Protection of National Infrastructure). http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-TC... Best Regards, Guillaume FORTAINE On 03/15/2010 06:04 PM, Deepak Jain wrote:

At first blush, I would say it's an interesting idea but won't actually resolve anything of the scariest DDOS attacks we've seen. (Unless I've missed something obvious about your doodle).

The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring.

You *can* punt those requests that are all identical to caches/proxies/IDS/Arbor/what have you and give higher priority to requests that show some differences from them... but you are still mostly at the mercy of serving them unless you *can* learn something about the originator/flow/pattern -- which might get you into a state problem.

Where this might work is if you are a large network that only serves one sort of customer and you'd rather block rogue behavior than serve it (at the risk of upsetting your 1% type customers). This would work for that. Probably good at stomping torrents and other things as well.

Best,

Deepak

...

-----Original Message----- From: Guillaume FORTAINE [mailto:gfortaine@live.com] Sent: Monday, March 15, 2010 2:57 AM To: nanog@nanog.org Subject: Re: OBESEUS - A new type of DDOS protector

Dear Mister Wyble,

Thank you for your reply.

On 03/15/2010 07:00 AM, Charles N Wyble wrote:

...

The paper is pretty high level, and the software doesn't appear to be available for download.

http://www.loud-fat-bloke.co.uk/obeseus.html

http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz

...

So it's kinda theoretical.

"We have it running parallel with a commercial product and it detects the following attacks ▪ SYN floods ▪ RST floods ▪ ICMP floods ▪ General UDP floods ▪ General TCP floods"

Best Regards,

Guillaume FORTAINE