NZ Firm Shows Anti-DDoS Tool 110
An Anonymous Coward writes: "ComputerWorld NZ is covering a story about a New Zealand company, Esphion Ltd having coverage at the recent JWID (Joint Warrior Interoperability Demonstration), with their anti-DDoS tool. From the article (here), it looks like it seems to work pretty well."
Re:Having just recently been to New Zealand.... (Score:1, Funny)
Re:Having just recently been to New Zealand.... (Score:1)
The Kiwis have a strong suspicion that some of them have gone a little "too rural", which is why many there consider Denial of Service as a ewe with a chastity belt.
The Ozzies get upset if you suggest that they have án unnatural relationship with sheep. Personally, I reckon it's guilt.
Re:Having just recently been to New Zealand.... (Score:1)
Re:Having just recently been to New Zealand.... (Score:1, Offtopic)
Re:Having just recently been to New Zealand.... (Score:1)
Re:Having just recently been to New Zealand.... (Score:2)
Comments like yours are exactly why I stopped reading Slashdot*. You may have visited New Zealand but that doesn't stop you being retarded and writing stupid brainless comments.
(* The only reason I'm posting here is because a friend sent me the link.)
I wonder if any anti-DDoS tool would help... (Score:5, Funny)
Re:I wonder if any anti-DDoS tool would help... (Score:1)
127.0.0.1 slashdot.org
to your hosts file, but that just turns one DoS into another.
On the other hand, we could just outlaw servers going down from too much load....
Re:I wonder if any anti-DDoS tool would help... (Score:1)
Nope, does not help agains /. :( I already got
http://199.57.1.141/cgi-bin/request/request.cgi
The page cannot be displayed
Re:I wonder if any anti-DDoS tool would help... (Score:5, Insightful)
(On the other hand, the slashdot effect often takes place because of the stress on the server, not the connection pipe itself, so a simple referrer denial would limit the effect rather much)
Re:I wonder if any anti-DDoS tool would help... (Score:1, Interesting)
Webscreen's trick in this case (a page flood or just very heavy demand) is to fail gracefully, letting the maximum number of users have access. It seems to work reasonably well in such cases, although they have only been shipping product since January 2002.
http://www.webscreen-technology.com for further info.
Content Delivery Networks (like Akamai) (Score:3, Interesting)
Even though slashdotting brings in a metric buttload of legitimate traffic, a Web site designed for high traffic scalability can include some kind of "surge protection", such as that provided by 'Content Deli ve ry Networks' such as Akamai, Mirror Image, etc.
Today's CDNs respond in realtime to traffic surges. If there's a sudden upswing in client-side demand, the CDN responds by distributing the content and the server-side load more widely across a larger number of servers, topologically selected to minimize network delays, etc.
Today the bottleneck with highly intereactive Web sites, even those that use CDNs, comes from the back-end databases that manage the content and drive the site. There's still lo ts of smart work to be done there with intelligent caching and content distribution.
-Mark Kriegsman
Founder, Clearway Technologies (which was subsequently purchased by Mirror Image),el
Re:I wonder if any anti-DDoS tool would help... (Score:2)
In short, it's very difficult to get auto-blackholing of IP addresses right without an attacker plunging your own sword into your stomach.
Re:I wonder if any anti-DDoS tool would help... (Score:3, Funny)
Oh wait... nevermind.
Yes! (Score:1)
Their tool will (if you configure it properly).
Re:I wonder if any anti-DDoS tool would help... (Score:2)
Moderators checklist:
Total: +5
it what now? (Score:3, Funny)
I guess it's pretty good at appearing to work.
Nothing really new... (Score:4, Interesting)
As far as detection goes, they use both traffic signatures and statistical anomaly detection. Meaning that yes, it can effectively block the /. effect (if not too well configured). Any rise in traffic that falls way outside the "usual" traffic pattern gets flagged as an attack.
Now as far as reaction goes, this is where it gets interesting. Not only can they configure local traffic control devices (router, firewall, etc) to block traffic, they can also escalate the traffic block to the next upstream router/firewall/etc. That, of course, requires some degree of collaboration from the upstream party.
As an example, this means that if you, at home, detect a SYN flood from a specific netblock, you can not only block it but you can tell your ISP to block it for you, automatically, in real time.
What remains to be seen is a) whether this is secure at all, or if there are flaws in the block-requesting protocol and algorithm, b) if service providers are willing and able to implement this kind of collaborative system to work on behalf of their users, and c) what kind of investment will service providers need in order to upgrade their routers/firewalls/etc so that they can process a potentially huge number of specific blocking rules for their customers. Yes, every rule requires router CPU, and yes, if you have too many of them, you need a bigger router or things start to slow to a crawl.
This kind of system is definitely good for you, but will it ever see light in commercial terms?
New Kind of Attack (Score:4, Insightful)
Could be nasty if not done right.
Re:New Kind of Attack (Score:2)
Re:New Kind of Attack (Score:2)
But what if that is a proxy, or a distribution of dial ups? Seems to me that even a good sysadmin would find themselves cutting off a lot of people.
Re:New Kind of Attack (Score:2)
Re:New Kind of Attack (Score:1, Interesting)
Not just the upstream blocking firewalls need to be secure (and I hope for all our sakes that those who run an isp know how to run a firewall) If any of the downstream systems is compromised (routers,servers, ids
- a few firewall blocked host/netblock looks like a "normal" reason for outage "they just should not have been ddosin us ya know"
- The system does not need to be compromised, just redirecting traffic *once* is enough, think about ill configured http proxy servers alowing a tcp connection to be redirected anywhere to allow https.
I wouldn't call it blocking the /. effect. (Score:3, Interesting)
As far as detection goes, they use both traffic signatures and statistical anomaly detection. Meaning that yes, it can effectively block the
From the article:
The first task is to detect either an anomalous rise in traffic volume, an unusual ratio between connection set-ups and tear-downs - the ratio being 1:1 in legitimate traffic - or a worm signature. The first necessitates careful analysis and subtraction of normal variability of traffic during the day. NetDeflect then identifies the nature of the spurious traffic and puts a filter in its way, or, in the case of a worm, disconnects the specific channel the worm is using.
Since it can't block all the 4000 source IP addresses of the /. effect if would have to block of the "channel", that is all traffic to the local HTTP port, effectively closing the shop for business .
It would be stretching it to call that "blocking the attack"
!! Nobody can block the /. effect !!
Re:I wouldn't call it blocking the /. effect. (Score:1)
Re:I wouldn't call it blocking the /. effect. (Score:2)
I don't think the slashdot effect would trigger this device. HTTP requests, AFAIK, is sent via ONE packet- this device should be looking for hosts sending it many packets, like would occur in a DDOS attack.
If you read the article you will see that they ale also looking for 'many hosts sending few packages'. A new Internet work for example. And the solution is to block the worm's channel (the port(s) used). The problem is that tis would also detect a sharp increase in potential custumers as a 'worm attack' and close the shop down for business.
Re:I wouldn't call it blocking the /. effect. (Score:2)
With apologies to Monty Python...
"Well, I didn't expect the Slashdot effect!"
"Nobody expects the Slashdot effect!"
Milalwi
Re:I wouldn't call it blocking the /. effect. (Score:1)
Re:I wouldn't call it blocking the /. effect. (Score:2)
By the time they can look at the referer header, the pacet has already eaten away their bandwith ..
Re:Nothing really new... (Score:3, Insightful)
I guess that's why it's been shown (and probably targeted) to military installations.
Re:Nothing really new... (Score:2)
Worse, you would be entitled to sue the reporter if you suffered from them misreporting the attack, eg by being cut off....
Where it does work is on a backbone connected router because you can shut off BGP peers and also play games adjusting routes to see which peer the actual attack comes down.
Re:Nothing really new... (Score:2, Insightful)
Re:Nothing really new...OT Rant (Score:2)
Like anyone ever clicks through to the actual articles and reads them. I salute you, Great American Hero---->Pasting-the-General-Idea-of-the-Story- Man! If it wasn't for you, 75% of
Actually, I think the redundant mod should be shot, same as over-rated. We need new mods:Duh, No shit, and Silly Flamer. Those could work just as well as under/over-rated.
But will it let the good stuf through? (Score:2, Redundant)
Re:But will it let the good stuf through? (Score:1)
It's the part about a ratio of 1:1 connections.
A spike would still be 1:1, whereas DDoS would be off that.
-- Tino Didriksen / Project JJ
Re:But will it let the good stuf through? (Score:1)
A spike would still be 1:1, whereas DDoS would be off that.
If I ping a server at 2 sec intervals, the 1:1 ration is maintained. If I and 5000 zombies ping a server at 2 sec intervals, the 1:1 ration is still maintained. But now it is a DOS attack that can bring down a slow connection. And the header doesn't have to have been altered, incidentally.
A combination of all 3 factors have to be taken into account to decide whether it is a DOS attack or not. The question of whether their algorithm is clever enough to do that and not impair legitimate traffic remains.
Re:But will it let the good stuf through? (Score:1, Insightful)
Re:But will it let the good stuf through? (Score:1)
I guess (Score:4, Insightful)
I think (Score:5, Funny)
Re:I think (Score:1)
funny how our enthusiasm killed it, huh?
People who wanted to see this project fail will say, "see- it's CRAP. they second they made it public, someone proved them wrong!"
even tho we're not what the tool was supposed to protect them against.
Re:I guess (Score:2)
You jest, but this is a good point. I'm currently refreshing Epherion's web site. Dive in, everybody, let's see if:
This should be interesting.
Re:I guess (Score:2)
Heh, that's Esphion [esphion.com], I mean.
Bullshit (Score:2, Informative)
But as of today's technology, there is NOTHING you can do if someone manages to overload your link. The only solution for your provider is to shut down your link (nullrouting you, for instance), which doesn't help you much
In the example given in the article, the only thing they do is preventing the DDoS to spread to other branches of their network, which it was unlikely to do anyway. The initial victim network remains down, and there's nothing they can do about that (unfortunately).
Re:Bullshit (Score:1)
wrong... Re:Bullshit (Score:2, Insightful)
This is one way to both identify and isolate the problem at a distance from the DDoS targets, that information can now be used to shut off the flood closer to the sources. How close is a matter of how deeply you arrange your defense.
I don't know if this is an element of what NetDeflect is using, they mention symmetry of connect creation/teardown. This is more expensive in terms of detection, but also more applicableto the local permiter.
Re:Bullshit (Score:1)
On another note it would be kinda cool if a system was ever developed that was close to fool-proof as far as dection of attacking IPs is concerned. It could be deployed intenet wide, made standard on routers and such. Then when someone tried to DDoS the routers, starting from the victim IP would block the attacking IPs back to their source. It would suck for those people with compromised PCs as their net connection was killed by their ISPs router but it would stop a lot of problems with this crap.
Now the problem with that kind of system is how do you tell what is good & what is bad traffic? Well, my guess is that problem is why a system like that doesn't already exist.
interesting but I think it could be done ... (Score:5, Interesting)
my idea (anyone wants to discuss? mail me: kipple at muug dot it) goes like that:
- once a traffic sensor (bandwidth sensor? Mtrg?) detects an abnormal increase of traffic coming from a particular source route, it contacts the first router it knows on that path to the flooding source; this first-hop router detects the next-hop router, until the source of the flood itself is found and either shaped (good) or blocked for a while (bad but necessary some times).
- all other legitimate connections can still pass through and reach the original service (being it a webpage or anything else), and only the flooders are blocked
- in today's anti-flood systems, it is only prevented for the server to crash under high load, but still the packets are coming down the wire. using the routers won't clog the wire of the victim
- also, there is no possibility to spoof those 'router communications', as there isn't today a way to fake OSPF or other protocols to fool routers. also cryptographically signed communications between routers could be implemented
- Plus, if a source route is spoofed, the router won't care (we're talking about low-level routing, not just IP based). So, no DNS spoofing and flooding (and therefore the site will still be able to access basic services - no blocking as in some misdesigned "active" firewalls).
I think that using this technique it will be possible to avoid many DOS-based attacks, but still not all: what if a LOT of zombies are requesting services from a particular website at a 'normal' rate? I fear thit has no solution: it resembles too much a normal user activity, and it is a problem of designing the services (or providing enough bandwidth, or splitting the service among different sites on different uplinks), and not a routing problem.
so, thoughts, suggestions?IP V6 (Score:2)
The other issue is variable IP. Many broadband users are given a variable IP to stop their customers from running servers. Once a user has bust a quote for a given IP address, they can just reconnect and probably get a new IP assigned and repeat the process. They may get the ISP address pool blocked, but that is an issue by itself if the ISP is big enough.
Re:IP V6 (Score:2)
also, if those customers have broadband, their IP is unlikely to change so quickly to fool a router update..
Re:IP V6 (Score:3, Insightful)
Re:IP V6 (Score:2)
oh well, therefore yours is another issue I haven't thought about. great.
Re:IP V6 (Score:2)
testing (Score:2)
And how does it stop forged DDOS? (Score:2, Interesting)
My proposal would be a giant lookup hash by IP, storing the number of active sessions between the protected network and the IP (or a CAM, but that may be kind of expensive). On receiving a SYN packet in "attack" mode, look up the IP address.
Now, if the number of sessions exceeds attack parameter, drop it and mark the IP as "attacking". Time out the IPs after a while to stop the hash from being huge.
If the number of sessions is zero, send a SYN-ACK, and mark the IP as "possible client". If the client responds with appropriate sequence numbers, proxy the tcp session to the target, forward the new packet, and increment the number of active sessions. If the client retransmits early, flag the IP as an attacker.
Now that is not perfect, but it will stop same IP-multiple session attacks, as well as making it harder on DDOS tools (must retransmit, but not too fast, limited to receivable IP addresses), which increases memory load, but most importantly means you can't forge addresses, so netblock blocks will work.
Re:And how does it stop forged DDOS? (Score:2, Informative)
Re:And how does it stop forged DDOS? (Score:2)
"When used in intercept mode (the default setting) it checks for incoming TCP connection requests and will proxy-answer on behalf of the destination server to ensure that the request is valid before then connecting to the server. Once TCP Intercept has established a genuine connection with the client and the server, it then merges these two connections into a single source-destination session. It offers a zero window to the client to prevent it from sending data until the server sends a window offer back. In the case of bogus requests, its use of aggressive time-outs on half-open connections and support of threshold levels for both the number of outstanding and incoming rate of TCP connection requests, protect servers while still allowing valid requests through."
telnet www.esphion.com 80 (Score:5, Funny)
Date: Tue, 28 May 2002 09:41:32 GMT
Server: Apache/1.3.19 (Unix)
FrontPage/5.0.2.2510 mod_ssl/2.8.3 OpenSSL/0.9.6b
I quess their product is so good, they can risk installing the frontpage extension in there. See who else thought so [interrorem.com] (defaced websites collection & HTTP info).
GPL'd DoS/DDoS detection tool (Score:3, Interesting)
I still maintain that its not the best solution... (Score:3, Funny)
Tests have shown that it is especially effective when aimed at the fingers, thus rendering the script kiddy unable to type
Re:such a good idea? (Score:1, Insightful)
10 ?
100 ?
10000 ?
DDoS harms the target, and all the others in between this target and the attacker. Think about it next time your emails are slow to download or when a website you're browsing is hardly responding...
Statistical != good (Score:4, Insightful)
Also, as others have mentioned, there's not much anyone can do about faked source IPs. Egress filtering would be a way to counter this, but for some reason not many ISPs do it.
Re:Statistical != good (Score:1)
Spoofed IPs are not a problem since you cannot easily ACK the server's SYN (since you'll never see it, thus no way to know ISN).
Echelon (Score:1, Offtopic)
Info found on (Score:2, Interesting)
Anti-DDoS technology is snake-oil (Score:2, Insightful)
If you are a Tier-2 ISP or a military network the tools will tell you the attack is coming from *gasp* the internet. You still will need to call upstream to filter the traffic.
This is such a useless technology without major backbone cooperation. People just don't get it.
Re:Anti-DDoS technology is snake-oil (Score:1)
What is it? (Score:1)
Zeus 4.1 has some anti-DDOS measures (Score:1)
I don't think it attempts to filter out all of the DDOS traffic specifically. I think it just tries to ensure that close to the maximum rate of requests can still be served under extraordinary load by quickly binning excess connections. It may even have some prioritisation of who gets binned.
It can also bin requests with particular signatures associated with known attacks.
Re:what a joke (Score:1)