How would one deal with a DDOS attack?
Results 1 to 11 of 11

Thread: How would one deal with a DDOS attack?

  1. #1
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,676

    How would one deal with a DDOS attack?

    I've noticed in the past couple of years that denial of service seems to be becoming a 'thing' for cyber criminals. Just this morning I saw this:
    http://redtape.nbcnews.com/_news/201...six-weeks?lite

    How would one protect against this sort of thing? I'm guessing the perpetrators are harnessing botnets but still wonder if it would be helpful to block vast IP blocks. Where does the bottleneck occur in a DDOS attack? Would it be the DNS server? Would it be Apache or a load balancer? How does one protect against this sort of thing?
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  2. #2
    Pna lbh ernq guvf¿
    Join Date
    Jul 2004
    Location
    Kansas City area
    Posts
    19,435
    The best way to protect against these sorts of attacks, I would think, is to partner up with someone as far upstream of you as you can. For example, blocking IP ranges at your server (via iptables, for example, using a DROP rule) will certainly protect Apache from getting hit, but the link(s) from your server to its upstream device(s) is/are still going to experience the bandwidth hit (not to mention your CPU will still feel the hit of analyzing all those packets before DROP'ing them).

    If, however, there was some sort of manual or automatic (e.g. with some fancy IDS or something along those lines) of alerting your internet provider(s) (or datacenter operators, etc.), having them block the traffic at their point(s) shields you even further upstream such that the equipment feeling the hit isn't even yours.

  3. #3
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,676
    Quote Originally Posted by bradgrafelman View Post
    The best way to protect against these sorts of attacks, I would think, is to partner up with someone as far upstream of you as you can. For example, blocking IP ranges at your server (via iptables, for example, using a DROP rule) will certainly protect Apache from getting hit, but the link(s) from your server to its upstream device(s) is/are still going to experience the bandwidth hit (not to mention your CPU will still feel the hit of analyzing all those packets before DROP'ing them).
    To talk to one's upstream provider is very good advice. If you are getting charged for traffic, DDOS could be financially crippling quite quickly if you don't ask for help. While this is not something that had occurred to me, I'm hoping to understand myself what techniques might be used in such cyber-combat.

    Quote Originally Posted by bradgrafelman View Post
    If, however, there was some sort of manual or automatic (e.g. with some fancy IDS or something along those lines) of alerting your internet provider(s) (or datacenter operators, etc.), having them block the traffic at their point(s) shields you even further upstream such that the equipment feeling the hit isn't even yours.
    It's my understanding that a well-organized DDOS attack will consist of traffic that is indistinguishable from legitimate traffic and that it will not be possible to isolate it to any particular IP block (i.e., it might come from a botnet).
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  4. #4
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,180
    I would suppose it depends somewhat on the nature of the attack. It's great if you can have someone upstream analyze and filter packets, but that may or may not be possible.

    Bandwidth costs aside, if the botnet's hitting your index page, or other legitimate pages, it's likely they'll succeed in a bit of DOS at least unless your system can keep up with the requests.

    Have you looked at (assuming Apache here) mod_evasive, mod_cband, mod_limitipconn, mod_bw, mod_bwshare etc?

    Ooh, and I still recommend FreeBSD over Linux, and mod_php over suPHP/suexec and friends (which I assume is the default cPanel-type server?). The big boys use nginx a lot, so I hear, often setup in reverse proxy. I've tried it, but not reverse proxy or with PHP ...
    Last edited by dalecosp; 04-08-2013 at 12:37 PM.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  5. #5
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,676
    Quote Originally Posted by dalecosp View Post
    Have you looked at (assuming Apache here) mod_evasive, mod_cband, mod_limitipconn, mod_bw, mod_bwshare etc?
    I have not. Will check those out.

    Quote Originally Posted by dalecosp View Post
    Ooh, and I still recommend FreeBSD over Linux, and mod_php over suPHP/suexec and friends (which I assume is the default cPanel-type server?). The big boys use nginx a lot, so I hear, often setup in reverse proxy. I've tried it, but not reverse proxy or with PHP ...
    I've definitely heard good things about FreeBSD and how secure it is. Not having ever installed it, I wonder if it has the package system for installing apache, etc?

    Could you elaborate on mod_php vs. suPHP/suexec?

    I've also heard of nginx, but what do you mean about setting it up "in reverse proxy?"
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  6. #6
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,180
    Quote Originally Posted by sneakyimp View Post
    I have not. Will check those out.


    I've definitely heard good things about FreeBSD and how secure it is. Not having ever installed it, I wonder if it has the package system for installing apache, etc?
    Code:
    $cd /usr/ports/www/apache22
    $sudo make install clean
    After that, rehash your shell and "apachectl start" ... plus all that config file editing and whatnot.
    Could you elaborate on mod_php vs. suPHP/suexec?
    I can try. When I set up PHP on FreeBSD I end up with PHP running as an Apache module (DSO). Anecdotally, at least, it outperforms the typical Linux approach which seems to be a cPanel installation and PHP is a CGI or something ... they're actually calling /usr/bin/php from within Apache somehow. I'm really no expert: https://www.google.com/search?q=suexec+php+vs+mod_php might help?

    I've also heard of nginx, but what do you mean about setting it up "in reverse proxy?"
    They're serving assets from multiple servers and/or domains through one server, usually nginx. So you can have a whole tribe of Apaches (or herd of Tomcats or whatever) doing the heavy lifting and sending the HTML to nginx, which feeds it all to the client.

    It's also a handy load balancer, I believe, if you set it up right.
    Last edited by dalecosp; 04-08-2013 at 04:54 PM.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  7. #7
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,180
    I'm going to bump this up, as I have a need related to it I'd like to discuss.

    This:

    Quote Originally Posted by sneakyimp
    It's my understanding that a well-organized DDOS attack will consist of traffic that is indistinguishable from legitimate traffic and that it will not be possible to isolate it to any particular IP block (i.e., it might come from a botnet).
    I'm having something akin to this happen Right Now(tm). I don't know that's it's intended as a DDOS attack, but think, rather, that it's perhaps a distributed scraping system, although it could be a DDOS (if it is, hmm ... it's certainly not the largest possible botnet, but it seems to be effective enough).

    What I'm wondering is this. It doesn't seem to be loading me up enough to zombify the server itself, but it is, rather, saturating MySQL's max_connections (which is set to default, 151). I can, obviously, up max_connections in my.cnf, but then I actually MIGHT run risk of zombifying the box.

    Some things I'm noting about the "attack". There are several IP's within similar netblocks (e.g. 1.2.3.4, and 1.2.3.15, and 1.2.3.233 are all involved). They each seem to get new SESSID's, at least they appear to in the logfiles (apparently don't take cookies and the system is giving them s=SESSID), and they are probably flipping the UA strings ("Mozilla", then "Safari", then "Chrome", "Linux", then empty, then "iPhone", etc.).

    So, how might I go about putting together a "plugin" for a PHP site/page(s) that might mitigate this sort of thing? What I'm thinking: Check the REMOTE_ADDR and see if it's been pretty busy lately ($n requests in the last $x seconds), then check the User-Agent string and see if it has been "bouncing around" (say, we have 4 different UA strings for this IP within the last $x seconds). See if the SESSION var is changed, and if we think it's nefarious based on enough of these criteria we die("Please go away!") ... your thoughts?

    Does it sound possible? Would it be potentially effective?
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  8. #8
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,676
    Quote Originally Posted by dalecosp View Post
    I'm having something akin to this happen Right Now(tm). I don't know that's it's intended as a DDOS attack, but think, rather, that it's perhaps a distributed scraping system, although it could be a DDOS (if it is, hmm ... it's certainly not the largest possible botnet, but it seems to be effective enough).
    Have you checked the IP block to see who it belongs to? You sure it's not a search crawler?

    Quote Originally Posted by dalecosp View Post
    What I'm wondering is this. It doesn't seem to be loading me up enough to zombify the server itself, but it is, rather, saturating MySQL's max_connections (which is set to default, 151). I can, obviously, up max_connections in my.cnf, but then I actually MIGHT run risk of zombifying the box.
    I've had max_connection settings MUCH higher than that. I don't recall what the exact risks are, but I vaguely recall having an Amazon RDS instance (i.e., managed mysql) and it had a ton of RAM and cpu muscle that simply wasn't being utilized. I was getting db connections refused under heavy traffic so I jumped this value (and a few others) and the box started actually using its gobs of RAM.

    Quote Originally Posted by dalecosp View Post
    Some things I'm noting about the "attack". There are several IP's within similar netblocks (e.g. 1.2.3.4, and 1.2.3.15, and 1.2.3.233 are all involved). They each seem to get new SESSID's, at least they appear to in the logfiles (apparently don't take cookies and the system is giving them s=SESSID), and they are probably flipping the UA strings ("Mozilla", then "Safari", then "Chrome", "Linux", then empty, then "iPhone", etc.).
    This *could* be a bunch of folks on a LAN behind a single ip -- e.g., an huge classroom full of students at some university? An audience at a TED talk? My apartment building before I booted the starving students off my WiFi? All those guys watching the cowboy movie in 'Brazil?' OR this could be some script running on one or more machines at that IP address. If it's actual visitors, then you should get more than one request for each session id. I think this is the key. If the ratio of unique_session_ids/requests from a particular IP is really high (i.e., close to 1) then that IP is not really using your sessions. Who do you ban and how do you ban them? For you to decide. I'd do a lookup on the IP blocks and if they are from some foreign country and totally irrelevant for your business, just block the whole IP block and be done with it.

    Quote Originally Posted by dalecosp View Post
    So, how might I go about putting together a "plugin" for a PHP site/page(s) that might mitigate this sort of thing? What I'm thinking: Check the REMOTE_ADDR and see if it's been pretty busy lately ($n requests in the last $x seconds), then check the User-Agent string and see if it has been "bouncing around" (say, we have 4 different UA strings for this IP within the last $x seconds). See if the SESSION var is changed, and if we think it's nefarious based on enough of these criteria we die("Please go away!") ... your thoughts?
    I think these are the criteria that merit banning:
    * same session ID accessed by different User-Agents (which would suggest a stupid script OR someone spoofing someone else's session)
    * ratio of unique_session_ids/requests from some particular REMOTE_ADDR approaching 1 (or even .8 or something).

    Quote Originally Posted by dalecosp View Post
    Does it sound possible? Would it be potentially effective?
    Certainly possible. Potentially effective. But the ol' ban hammer might also punish innocents. I'd give it a whirl. Legitimate users will likely find some way to complain about it if it's important to them.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  9. #9
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,180
    Quote Originally Posted by sneakyimp View Post
    Have you checked the IP block to see who it belongs to? You sure it's not a search crawler?
    Certain enough to say "yes", unless it's a world-wide distributed crawler that doesn't see fit to issue legit UA strings, etc. While there are plenty of distributed crawlers, if they're not nice enough to wear a name tag, (or so useless as to be, well, useless [/me glares at 'aboundex.com']) we're not interested in them.

    I've had max_connection settings MUCH higher than that. I don't recall what the exact risks are, but I vaguely recall having an Amazon RDS instance (i.e., managed mysql) and it had a ton of RAM and cpu muscle that simply wasn't being utilized. I was getting db connections refused under heavy traffic so I jumped this value (and a few others) and the box started actually using its gobs of RAM.
    Economic times being what they are (at least in our business), this box is rather modest (Dual CPU VM with 2 GB RAM). I can *probably* up max_connections, but it's been serving legit traffic Just Fine for a couple years without this happening much, if ever.

    This *could* be a bunch of folks on a LAN behind a single ip -- e.g., an huge classroom full of students at some university? An audience at a TED talk? My apartment building before I booted the starving students off my WiFi? All those guys watching the cowboy movie in 'Brazil?' OR this could be some script running on one or more machines at that IP address. If it's actual visitors, then you should get more than one request for each session id. I think this is the key. If the ratio of unique_session_ids/requests from a particular IP is really high (i.e., close to 1) then that IP is not really using your sessions. Who do you ban and how do you ban them? For you to decide. I'd do a lookup on the IP blocks and if they are from some foreign country and totally irrelevant for your business, just block the whole IP block and be done with it.

    I think these are the criteria that merit banning:
    * same session ID accessed by different User-Agents (which would suggest a stupid script OR someone spoofing someone else's session)
    * ratio of unique_session_ids/requests from some particular REMOTE_ADDR approaching 1 (or even .8 or something).
    Thanks ... that's more/less where my thought process was headed. However, I'd considered just politely showing them a page that said "please stop", rather than manipulating FW rules via PHP, which seems like a potential way of DDOSing *myself* if something went haywire or the "Perfect Storm" approached.

    One of the bigger questions, actually, is the real LOGIC of the thing. For example, since I'm trying to safeguard MySQL, more or less ... should my "guard program" actually *use* MySQL itself ? I may end up parsing some files, anyway. I wonder if I could have it somehow get a number of requests per second from Apache? Hmm.


    Certainly possible. Potentially effective. But the ol' ban hammer might also punish innocents. I'd give it a whirl. Legitimate users will likely find some way to complain about it if it's important to them.
    Thanks for the comments.
    Last edited by dalecosp; 09-23-2015 at 12:39 PM.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  10. #10
    Senior Member
    Join Date
    Apr 2003
    Location
    Flanders Fields
    Posts
    5,676
    Quote Originally Posted by dalecosp View Post
    Certain enough to say "yes", unless it's a world-wide distributed crawler that doesn't see fit to issue legit UA strings, etc. While there are plenty of distributed crawlers, if they're not nice enough to wear a name tag, (or so useless as to be, well, useless [/me glares at 'aboundex.com']) we're not interested in them.
    Banhammer!

    Quote Originally Posted by dalecosp View Post
    Economic times being what they are (at least in our business), this box is rather modest (Dual CPU VM with 2 GB RAM). I can *probably* up max_connections, but it's been serving legit traffic Just Fine for a couple years without this happening much, if ever.
    Command "free" on linux should tell you how much RAM is actually used. Look under row that says "swap" under column that says "used". If it's zero, you might be able to squeeze the number up. Once you start using the swap, the machine will start to slow dramatically. Hope I'm not telling you something you already know.

    Quote Originally Posted by dalecosp View Post
    Thanks ... that's more/less where my thought process was headed. However, I'd considered just politely showing them a page that said "please stop", rather than manipulating FW rules via PHP, which seems like a potential way of DDOSing *myself* if something went haywire or the "Perfect Storm" approached.
    You might consider a temporary ban for "flooding" your system. Very simple: too many requests from one IP, ban them for X minutes and show a message. Might consider some kind of moving average -- I forget the exact mathematical term or technique, but you would store a single value for each IP that represents its "load average over time" or whatever.

    I'm thinking each IP address gets a few records:
    * ip_address
    * request_microtime

    Every time a request comes in, you need to recalculate the time_weighted_average some how. My math mind is not working today, but
    * you'd need to purge records beyond some certain time or record count
    * the more records you keep, the more accurate your moving average. One record only could result in false positives if you get two requests too close to each other
    * in simplest version A, you just keep N records and if the time between the first request and the most recent one falls below some threshold, then BAN the IP
    * in simplest version B, you keep a record of all requests in the past N seconds and when that number of records exceeds some threshold, BAN the ip

    Quote Originally Posted by dalecosp View Post
    One of the bigger questions, actually, is the real LOGIC of the thing. For example, since I'm trying to safeguard MySQL, more or less ... should my "guard program" actually *use* MySQL itself ? I may end up parsing some files, anyway. I wonder if I could have it somehow get a number of requests per second from Apache? Hmm.
    Parsing a file might introduce load on your file system or you might have too many processes competing for the same file. If you could limit the ban/firewall logic you are considering to some small set of IP addresses, this might be a good approach. Or you could keep one text file for each IP address to prevent your various processes from fighting over some single data file. Interestingly, if you have on data file per remote_addr, then it might introduce an interesting bottleneck if you are getting a bazillion requests from some single IP.

    Quote Originally Posted by dalecosp View Post
    Thanks for the comments.
    Of course! I love this security stuff. Perhaps you can reciprocate by helping me with this.
    IMPORTANT: STOP using the mysql extension. Use mysqli or pdo instead.
    World War One happened 100 years ago. Visit Old Grey Horror for the agony and irony.

  11. #11
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,180
    Quote Originally Posted by sneakyimp View Post
    Of course! I love this security stuff. Perhaps you can reciprocate by helping me with this.
    Ooh, iOS ... from a webpage ... that'd be a bunch of JavaScript, I guess.

    I could, probably, um ... help with reformatting your tabs and spaces
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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