Results 1 to 7 of 7
  1. #1

    DoS Attack from a business point of view...

    Okay, you have a client who's site gets targetted (We're not talking an adult site, more of a community site) and some *@#(! decides to hit it from ~150 seperate IPs, regular http requests for the same file repeatedly, multiple requests per second per machine. Total damage before your cPanel bandwidth monitor catches it and locks out the account? 60+ Gigs.

    What do you do going foward? You can't actually firewall off these kinds of attacks (unless you close off port 80?). Sure, you ipdrop those 150 attacking IPs, but what happens after the guy finds more machines?

    Do you seriously try and billing your client $120+ for usage that really wasn't his doing? Even if the site in question is on a ded box and you're not too worried about you going over your monthly limit at this point (ie: You aren't going to be billed out for the attack yet, and you'd have to have a HECK of a month to hit that limit even with the attack)

    Ideas? Suggestions? Feedback? Novel approaches to keeping these idiot kiddies at bay?
    Pure Energy Systems

  2. #2
    Join Date
    Jan 2002
    I dont think you can justify billing the client in any way.. thats just how this business works.. you could always shut his account for using too many resources as long as its in your TOS that would be a honest reason..

  3. #3
    Join Date
    Nov 2001
    if it is a problem, tell the person to change the name or location of that one file so when the person doing the attack wont know where it is.

  4. #4
    Join Date
    Jun 2000
    Alabama of course
    From the sounds of it that might have been a vbulletin mysql attack.. although it could have just been a simple bandwidth attack as well targeted at running someones bill up..

    It all comes down to choice really... your ISP bills you for that bandwidth so the question is, do you (can you) eat the cost or do you pass it on? Either is fine in my book as its a decision each and every host must make. There's really no way to stop those types of attacks... if its mysql based then limiting the number of max sql connections per user helps hold back the damage as would limiting the max # of connections each apache virtual host can have... but in the end if people want to cause damage they will... so its really up to the host if they can afford to eat the costs or not.. after all it was their site and half the time attacks are provoked in some way or another even if the site owner may not realize it at the time....
    KnownHost Managed VPS Specialists
    Fully Managed VPS, Hybrid,and Dedicated Servers
    KnownHost is hiring! Click here for more information!

  5. #5
    Join Date
    Jun 2002
    Toronto, Ontario
    I think the only thing you can do is pro-actively monitor network usage so that it doesn't get that extreme and you can start to block it off when its minimal.

    It isn't the clients fault. Unless the client had something to do with it. But how can you find that out?
    Kaumil P.

  6. #6
    Join Date
    Feb 2002
    Discuss with the client what has happened and tell them how much it is has cost you in terms of bandwidth, see if they will give you a contribution towards it, who knows the client may be happy to pay 100% for his overage caused by the attack, but then again they might say go to hell

  7. #7
    Well, given the fact that we never go anywhere near our limit on that particular server, we can eat this round without too much impact (if any) on our bottom line. Just a stressful situation.

    We had all the normal monitoring scripts in place, which is actually how we found out about it.. just that by the time Apache started falling over on itself and triggered the alarm, the bulk of the damage had been done.

    I already advised the client that there's not a whole lot we can do proactively to keep this kind of thing from happening (Short of limiting port 80 connections per second/minute, and that would throttle the entire box).. and we'll see what happens...
    Pure Energy Systems

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts