Slashdot Mirror
NZ Firm Shows Anti-DDoS Tool
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."
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?
free the mallocs!
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 !!
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
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?-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)
How would you propose to stop forged DDOS from netblock 0/0? Since this is how most DDOS tools operate, and one would assume that any credible attacker was able to send forged packets onto the net, I'd be very interested to know this. You can't solve the problem with upstream blocking unless you are willing to cut off a possibly very large portion of the net.
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.
Readers may want to have a look at a GPL'd DoS/DDoS detection tool under development at the moment, found here.
-- fsck your brains
If the up-stream blocking controls have security flaws, a new kind of attack might become popular: wall off sites instead of flood them.
;-) ) and used to create a forged blocking request it has the same effect. I could see a time where there is no longer a third ids like system deciding who goes on the firewall block list but becouse of cost saving and simplicity the web(or mail,dns or irc) server gets to do it. This would be really scary becouse these systems actually need to have listening services running which make them far more vulnarable to compromise. Those who think "but if the webserver gets compromised, don`t the atackers have their objective anyway, just rm -rf / and voila, server toasted!"
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.
There is at least one DDoS mitigation device that would handle the /. effect - at least to some degree. Webscreen Technology makes an inline DDoS device which uses IP address history and information about the server or server farm it is defending to prioritize incoming and outgoing traffic. When a web server begins to reach saturation a Webscreen box begins to drop packets and requests based on what it knows about the IP address and what the servers can handle - this maximizes the number of users that can access a web site and reduces or eliminates crashes due to overloading web servers (IIS is notorious for this) but in the final analysis there are only so many HTTP requests that can be handled by a given URL, and once that limit is reached there just isn't enough to go around.
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.
An interesting read. Recommendations for the Protection against DDOS found at the task force sicheres internet )
Actually, I think the answer is yes.
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