Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security

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."
This discussion has been archived. No new comments can be posted.

NZ Firm Shows Anti-DDoS Tool

Comments Filter:
  • by DocSnyder ( 10755 ) on Tuesday May 28, 2002 @04:47AM (#3593951)
    ...against the /. effect.
    • actually it could be a virus adding

      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....
    • >...against the /. effect.

      Nope, does not help agains /. :( I already got

      http://199.57.1.141/cgi-bin/request/request.cgi
      The page cannot be displayed

      /. effect rocks! Nothing escapes it!

    • by ymgve ( 457563 ) on Tuesday May 28, 2002 @04:57AM (#3593966) Homepage
      I know you were joking, but the answer is no. The problem with a slashdotting is that it is completely legitimate traffic from tens of thousands of different sites. As far as I figured it out, these guys dynamically block IPs that are identified as DDOS participants (Since a DDOS has far lesser 'attackers' than a slashdotting) and can then make the network more resistant to all the traffic.

      (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)
      • by Anonymous Coward
        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.
      • 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
      • Fantastic! Then all the attacker needs to do is send packets which trip the anti-DDoS software, spoofed to look like they're coming from the target's upstream router, [the target's / the target's ISP's] DNS servers, the root nameservers... the list goes on and on.

        In short, it's very difficult to get auto-blackholing of IP addresses right without an attacker plunging your own sword into your stomach.
    • The only known defense against slashdotting is to have a crappy unimportant website.

      Oh wait... nevermind.
    • by Banner ( 17158 )
      www.captusnetworks.com

      Their tool will (if you configure it properly).
    • Moderators checklist:


      • Mentions Slashdot effect ... +5
      • Mentions moderation ... no
      • Mentions beowulf cluster ... no
      • Erotic fan fiction ... no

      Total: +5

  • by AndyChrist ( 161262 ) <<andy_christ> <at> <yahoo.com>> on Tuesday May 28, 2002 @05:00AM (#3593973) Homepage
    "it looks like it seems to work pretty well."

    I guess it's pretty good at appearing to work.

  • by juliao ( 219156 ) on Tuesday May 28, 2002 @05:00AM (#3593974) Homepage
    For those of you who haven't read the article, the tool works, like so many others, in 2 ways: detection and reaction.

    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)

      by OffTheRack ( 551671 ) on Tuesday May 28, 2002 @05:04AM (#3593982)
      If the up-stream blocking controls have security flaws, a new kind of attack might become popular: wall off sites instead of flood them.

      Could be nasty if not done right.
      • Any sysadmin with sense would of course allow the machine to be blocked only by request from the downstream link, rather than a request coming off the backbone. However, with the ineptitude of a few sysadmins screwing things up for everyone (think open relays [spam.com]), this does seem like it could cause harm in the wrong hands.
        • Any sysadmin with sense would of course allow the machine to be blocked only by request from the downstream link

          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.
          • How would it cut off a lot of people? My understanding of the technology is that it can dynamically set up a filter that denies a specific group of source IP addresses. The only real problem is the possibility of an outside attacker to set up a filter that applied to all IPs, effectively walling off a computer from the Internet.
      • by Anonymous Coward
        If the up-stream blocking controls have security flaws, a new kind of attack might become popular: wall off sites instead of flood them.

        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 ;-) ) 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!"

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

    • 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).

      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 !!

    • Agreed - commercial use would be possible but to make it meaningful, co-operation between providers is a must. Otherwise it becomes very expensive.

      I guess that's why it's been shown (and probably targeted) to military installations.

    • Its been known in the network community that filtering by source address of attacks does not work for the general case. It has been known for years. With such a system if I attack them spoofing your address range they shut *you* off and automatically alert your isp.

      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.
    • I find this very amusing that the parent post is modded redundant.

      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 /. would be posting uninsiteful drivel....oh wait. But I digress.

      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.
  • I accept that a tool such as this can successfully detect and stop DOS attacks, but is it clever enough to allow for legitimate spikes? If anything, I think that the real challenge is in sorting the binary wheat from the chaff and while the article does make mention of this factor, it doesn't say that normal traffic spikes were ignored and allowed to complete their transactions during an attack.
    • Actually, they did take that into account.
      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
      • I thought the article quite clearly stated that it weighs (a combination of) 3 things:
        1. increased volume
        2. 1:1 setup to breakdown ratio
        3. worm signatures
        Of the above 1 and 2 can very possibly be due to legitimate transactions; 3 too, if you just happen to be very, very unlucky.

        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.
    • by Anonymous Coward
      The other assumption is that it's not inspecting packets, which any decent DDOS screener would be doing. Simply looking at how many connections is irrelevant, as many attacks are based on having slightly warped packet headers - ok enough to pass through most things, but messed enough to lock up a specific host/router/what have you. When they're talking about signatures, they don't just mean traffic shape, but entire header signatures. Hence, normal traffic that lacked that matching signature wouldn't be touched.
    • I would assume that there's more to this than just mere ratios. There also has to be a lot of statistics involved. One of the major reasons why statistics developed in the early part of the 20th century was because Ma Bell wanted as much uptime as possible (i.e. the Five Nines). I'm sure there must be some translation of the telephony approach.
  • I guess (Score:4, Insightful)

    by MrFredBloggs ( 529276 ) on Tuesday May 28, 2002 @05:13AM (#3593995) Homepage
    someone will target them now, to test their claims!
    • I think (Score:5, Funny)

      by gusnz ( 455113 ) on Tuesday May 28, 2002 @05:53AM (#3594038) Homepage
      we just did!
      • In all truth; yeah, we just did. We were one of those unforseen accidents. the sad part is, while we had nothing to do with their tool(besides curiousity to see it) we will be blamed as something trying to prove it doesn't work.

        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.
      • someone will target them now, to test their claims!

      You jest, but this is a good point. I'm currently refreshing Epherion's web site. Dive in, everybody, let's see if:

      1. They're eating their own dog food (using their own system)
      2. It can distinguish between an attack and heavy but legitimate traffic.

      This should be interesting.

  • Bullshit (Score:2, Informative)

    by Anonymous Coward
    Tools to defend against SYN floods, fragmentation attacks and the likes have been available for a long time (think SYN cookies, for instance). In that regard, this product is probably a good solution.

    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).
    • Indeed. So now, the only thing you need to dos someone, is to generate some strange traffic that you know will trigger the ddos alert, and automatically that branch of their network will be closed from the rest. Since disrupting the network is usually the purpose of these attacks, this is hardly protection.
    • by fw3 ( 523647 )
      DDoS attacks use spoofed addresses. This generates traffic asymetry in the upstream routers (e.g. more SYNs than ACKs come through the routers that are gating the DDoS, more ACKs than SYNs return toward the spoofed IPs. Using this for isolating DDoS sources was presented at the '01 Usenix security symposium.

      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.

    • The article and the company's site went into some depth on how this problem (over-loading of the users link) is prevented. The next major router above the target IP(s) would have to have client software of some sort installed which would allow the router with the larger link to filter the bad packets before they ever flood your link. Now I realize there is still the problem of what if the attack is large enough to take down the router above you? I imagine if (when) a system like this is deployed for a large corperation or government it would be deployed as far up the router path they could go to kill the flood as far away from the target IP as possible.

      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.
  • by kipple ( 244681 ) on Tuesday May 28, 2002 @05:37AM (#3594013) Journal
    ...using no "software" but, say, any standard routing protocol.
    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?
    • AFAIK, IPV6 has some optional facilities for cryptographically signing router updates. Some major backbones are V6 but the real world isn't.

      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.

      • true. but since those attacks come from many countries, and mostly all of those countries have pay-for-use internet connection, customers will notice if their pc will hang up and redial the ISP number.
        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)

          by Slashamatic ( 553801 )
          Not if you are on ADSL or broadband (the DOSer's favourite target). You have a permanent link to the net, the links are usually programmed to resestablish themselves automatically. The ISP will usually then allocate a fresh IP address for each connection attempt. Total timout, a few seconds.
          • well here in Italy many IP addresses remains the same until the connection drops (due to power outage, and such). didn't know those ISP were putting so much effort in making their customers avoid setting up their websites.. are they afraid their customers will do e-commerce and make money from it? damn....

            oh well, therefore yours is another issue I haven't thought about. great.
      • by Cato ( 8296 )
        You can already sign routing updates with BGP (using MD5 authentication) and probably with other protocols as well. BGP is the most important one of course because it is used between ISPs.

  • i wonder if they tested by hitting big ecommerce sites for 6 straight days [slashdot.org] in order to develop the tool
  • 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.
    • I know it won't always help, but source 0/0 should be blocked at the perimeter anyway, those are considered aliens.
    • What you propose has been available on Cisco routers for about 2 years. It's called TCP Intercept: [cisco.com]

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

  • by jukal ( 523582 ) on Tuesday May 28, 2002 @05:53AM (#3594039) Journal
    HTTP/1.1 200 OK
    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).
  • by ckotso ( 121347 ) on Tuesday May 28, 2002 @06:02AM (#3594048)
    Readers may want to have a look at a GPL'd DoS/DDoS detection tool under development at the moment, found here [sourceforge.net].
  • by GnomeKing ( 564248 ) on Tuesday May 28, 2002 @06:26AM (#3594076)
    The industry standard baseball bat has a much better effect, is longer lasting, does not require uplink co-operation and is considerably cheaper

    Tests have shown that it is especially effective when aimed at the fingers, thus rendering the script kiddy unable to type ./DoS ip
  • by Quixote ( 154172 ) on Tuesday May 28, 2002 @07:51AM (#3594180) Homepage Journal
    The problem with such 'statistical' tools is that statistics can easily be faked. For example: since they are looking for a 1:1 ratio between SYNs and FINs, all the DDoS initiator has to do is alternate between SYNs and FINs.

    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.

    • If the device has any interest in TCP state, it would ignore the FIN unless the usual SYN+ACK, ACK sequence followed the client's initial SYN. Most SYN proxies (what I would classify this device as) watch initial state quite closely, so I doubt such an "attack" would prove useful.

      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)

    by gambit3 ( 463693 )
    don't the participating countries (US, Australia, New Zealand, Canada and the UK,) sound suspiciously like the prime Echelon members? [aclu.org]
  • Info found on (Score:2, Interesting)

    An interesting read. Recommendations for the Protection against DDOS found at the task force sicheres internet [www.bsi.de] )
  • by Anonymous Coward
    Without the cooperation of ever Tier-1 ISP (UUNET, C&W, Qwest, Sprint, etc.) and router/switch vendor (Cisco, Juniper) this technology will never work. You need to have the anti-DDoS devices installed at every ingress point to sample traffic. News Flash! The major ISP's are barely making it financially as it is, why are they going to build out new infrastructure now? Attack traffic causes customer links to burst, thus increasing ISP fees. Dirty little secrect of bandwidth providers: "DoS attacks make them money. Why stop them?"

    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.
    • Yawn... Yes, yes, very interesting, now tell me, have you actually read the website? If you had you would have found out that it is using the available router infrostructure when deployed in controller mode. And why just sample traffic? If you are the military I'd expect the active mode in combination with controller mode to be implemented. Which *gasp* FILTERS the traffic. So why call upstream? It seems that you appear to have missed the point that NetDeflect actually performs filtering, and not just graphical sampling ( which is also avalable, and in most cases, included with all versions of the product). I suggest you do your research a little more next time. Also read the "Having Seen The Product" Post, it is actually written by someone who knows what they are talking about.
  • A combination LDAP client and baseball bat?
  • http://www.zeus.com/news/articles/020307-001/

    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.

Quantity is no substitute for quality, but its the only one we've got.

Working...