OBESEUS - A new type of DDOS protector

Mailman List Mirror (Read Only)
1

Misters,

Let me introduce myself : Guillaume FORTAINE, Engineer in Computer
Science. I am currently working on High-Speed Network Security
Solutions.

DDoS is considered as "The Mother of All Cyber Threats" [1] therefore I have intensively studied this topic.

By the way, I have read with interest the NANOG mails [2] [3] [4] and the Linkedin groups [5] [6] on this subject.

Being an FPGA engineer, I approached this concern from an algorithmic point of view and that's why I would greatly appreciate to have your comments on this project, if possible, please :

"OBESEUS - A new type of DDOS protector" [7]

http://www.loud-fat-bloke.co.uk/obeseus2.pdf

For a better overview of the background of the project, please see the following document :

"INQUIRY INTO EU POLICY ON PROTECTING EUROPE FROM LARGE SCALE CYBER-ATTACKS"

http://www.parliament.uk/documents/upload/F012Interoute121109.pdf

I look forward to your answer,

Best Regards,

[1] http://events.linkedin.com/Webcast-DDoS-Mother-All-Cyber-Threats/pub/171074
[2] http://mailman.nanog.org/pipermail/nanog/2009-November/014963.html
[3] http://mailman.nanog.org/pipermail/nanog/2010-January/016675.html
[4] http://mailman.nanog.org/pipermail/nanog/2010-January/017604.html
[5] http://www.linkedin.com/groups?home=&gid=2040519
[6] http://www.linkedin.com/groups?home=&gid=2632190
[7] http://www.loud-fat-bloke.co.uk/obeseus.html

Guillaume FORTAINE
Tel : +33(0)631092519

2

Misters,

No comments ?

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

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

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

I look forward to your answer,

Best Regards,

Guillaume FORTAINE

3

Guillaume FORTAINE wrote:

Misters,

No comments ?

obeseus2.pdf

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

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.

4

Dear Mister Wyble,

Thank you for your reply.

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

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
:black_small_square: SYN floods
:black_small_square: RST floods
:black_small_square: ICMP floods
:black_small_square: General UDP floods
:black_small_square: General TCP floods"

Best Regards,

Guillaume FORTAINE

5

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

6

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 frame this new embodiment as something called EDoS — economic denial of sustainability. Distributed Denial of Service (DDoS) attacks are blunt force trauma. The goal, regardless of motive, is to overwhelm infrastructure and remove from service a networked target by employing a distributed number of attackers. An example of DDoS is where a traditional botnet is activated to swarm/overwhelm an Internet connected website using an asynchronous attack which makes the site unavailable due to an exhaustion of resources (compute, network, or storage.)

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.

An example of EDoS as a variant of click fraud is where a botnet is activated to visit a website whose income results from ecommerce purchases. The requests are all legitimate but purchases are never made. The vendor has to pay the cloud provider for increased elastic use of resources but revenue is never recognized to offset them.

We have anti-DDoS capabilities today with tools that are quite mature. DDoS is generally easy to spot given huge increases in traffic. EDoS attacks are not necessarily easy to detect, because the instrumentation and business logic is not present in most applications or stacks of applications and infrastructure to provide the correlation between “requests” and “ successful transactions.” In the example above, increased requests may look like normal activity. Many customers do not invest in this sort of integration and Cloud providers generally will not have visibility into applications that they do not own.

Best Regards,

Guillaume FORTAINE

7

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.

8

Dear Mister Morrow,

Thank you for your reply.

To quote :

"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. "

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."

Best Regards,

Guillaume FORTAINE

9

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"

10

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"

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.

-chris

11

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.

12

Misters,

Thank you for your reply.

1) First of all, I am absolutely not related to the Obeseus project.

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

13

If only there were other security experts on this list with a proven ability to make this thread even more absurd.

14

At your service.

;>

15

Mr. Fortaine, I am in communication with the gentlemen you address in
your latest email on very rare occasions. I ask questions that are way
out of my league, yet they answer me with honest information in an
attempt to answer my novice queries
  These guys could beat the hell out of me with the amount of knowledge
they have, and as they are knowledgeable, they also have varying
personalities.
  These guys were not being mean or hurtful. They were letting you know
what they thought and you asked for it.
  Sincerely, Richard Golodner

16

Dear Mister Dobbins,

Thank you for your reply.

What do you think about Obeseus ?

I look forward to your answer,

Best Regards,

Guillaume FORTAINE

17

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 :wink:

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

18

Not to mention that it is only "open source for private non-commercial
use only", and is crippled.

Also, Obeseus doesn't seem to be any better then stuff I have made
myself for my own usage and clients' usage. All it does it look at a
pcap dump and analyze it.

Obeseus is actually worse: it does not work in realtime, the data
structures it uses are not suited to realtime detection, and in a DDoS,
I think this could take several minutes to trigger appropriate events
like IP nullroutes and ACLs etcetera.

The best way to detect DDoS is to run a 30 second rolling average. If
you're suddenly doing a gigabit inbound within 30 seconds of UDP
traffic, you're probably being DDoSed ;).

William

19

Is this a joke of some kind ?

J

20

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.

Scalability in terms of logically centralized detection/classification/traceback and minimizing the insertion of additional hardware devices into the network should be core design principles of any operationally viable solution in this space.

Volume is only one input into an operationally-viable detection/classification system.

Traceback is also very important from an operational perspective.

ASIC-based edge routers do an excellent job of mitigating simple high-pps packet-flooding attacks via D/RTBH, S/RTBH and flowspec - again, the utility of these techniques has been validated by the operational community.

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.

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>