3 ms·

> 1) How do we confirm if the site is under attack? It could be some kind of attack, but it's so weak it barely qualifies. 50-100 requests is so low it's proba

by Udo 13y ago

> 1) How do we confirm if the site is under attack? It could be some kind of attack, but it's so weak it barely qualifies. 50-100 requests is so low it's probably a search engine spider or a log-spamming bot. If request rates like these bring your site down, you have a serious software problem. You really should be able to handle at least a few hundred requests per second, especially if they're bogus requests going to non-existent URLs. > 2) If the site is under attack, how can we ward off the attack and prevent future ones? If this was a real attack, you'd be dealing with thousands of requests per second and a real spike in data volume. As a basic protection against things like these, get behind a reverse proxy right now. Cloudflare offers a good free plan, but it doesn't include SSL. I've had a good experience with X4B as a DDoS-protection reverse proxy recently. Their plans start at a few bucks per month, check them out. > 3) We seem to have a ton of sleeping MySQL connections that continue to crop up even after we try killing them. Is this symptomatic of a botnet attack? This question can't be meaningfully answered without knowing more about your setup. Generally, sleeping connections are fine - most web servers create a persistent connection pool. What's "a ton" in this case? I think the only really valuable advice to give here is: hire someone to review your setup, your software, to make some changes, and above all to give you a meaningful briefing. Contacting your provider isn't going to help.

fragsworth 13y ago
> If request rates like these bring your site down, you have a serious software problem. This true only if the requests that are being sent to them aren't malicious. A competent attacker without a botnet can try to find weak points in your application (clearing caches, writing data) and hit those places with just a few network connections.
- Udo 13y ago
  > A competent attacker without a botnet can try to find weak points in your application They can, but it this case it sounds unlikely. It's not feasible for a potential attacker to bother with this kind of analysis and then just send a few dozen requests per second. Instead they can just pay $5 to a Russian bot net operator who will inundate the site with hundreds of thousands of requests. Even from a single mid-range DSL line alone one could launch thousands of HTTP requests without breaking a sweat.
panabee 13y ago
Agreed, the site is terribly antiquated and poorly coded. I helped to clean some of the code, but there is regrettably still a lot of ugly, ugly, heinous, ugly, ugly code. There are definite issues that require addressing. If this helps with diagnosis, here's IP data related to requests: https://gist.github.com/panabee/9595411 https://gist.github.com/panabee/9595411. Can post more if more is needed. Thanks so much for your help!
- Udo 13y ago
  It looks more like an attempt at spamming, but without the full log entries (containing the referrer and the destination URL) it's impossible to be sure. In the end it doesn't really matter though. Anyway, you have identified the main issue: some more code cleanup is in order. If you want to do this yourself: keep in mind that elegance in code is not the primary goal, runtime behavior is. Make sure you cache your results as much as possible, eliminate unnecessary DB calls. On the sysadmin side, assuming your app is PHP the following is mandatory: make sure you're using PHP-FPM, and enable APC or Opcache. Optionally, consider installing Memcached and start using it from the app to cache data that is expensive to generate. If you're running on Apache, switch to Nginx. Finally: reverse proxy service. They'll filter out most malicious requests for you. When the day comes where you experience a real attack, you'll have no chance of keeping the server up without using such a service.
joelcollinsdc 13y ago
> If request rates like these bring your site down, you have a serious software problem. Either that or you chose a CMS to host your website (Drupal Commerce?). 50-100 uncached application requests/sec is pretty high for a larger (in terms of number of contributed modules) drupal site

by Udo 13y ago

fragsworth 13y ago

> If request rates like these bring your site down, you have a serious software problem. This true only if the requests that are being sent to them aren't malicious. A competent attacker without a botnet can try to find weak points in your application (clearing caches, writing data) and hit those places with just a few network connections.

Udo 13y ago
> A competent attacker without a botnet can try to find weak points in your application They can, but it this case it sounds unlikely. It's not feasible for a potential attacker to bother with this kind of analysis and then just send a few dozen requests per second. Instead they can just pay $5 to a Russian bot net operator who will inundate the site with hundreds of thousands of requests. Even from a single mid-range DSL line alone one could launch thousands of HTTP requests without breaking a sweat.

panabee 13y ago

Agreed, the site is terribly antiquated and poorly coded. I helped to clean some of the code, but there is regrettably still a lot of ugly, ugly, heinous, ugly, ugly code. There are definite issues that require addressing. If this helps with diagnosis, here's IP data related to requests: https://gist.github.com/panabee/9595411 https://gist.github.com/panabee/9595411. Can post more if more is needed. Thanks so much for your help!

Udo 13y ago
It looks more like an attempt at spamming, but without the full log entries (containing the referrer and the destination URL) it's impossible to be sure. In the end it doesn't really matter though. Anyway, you have identified the main issue: some more code cleanup is in order. If you want to do this yourself: keep in mind that elegance in code is not the primary goal, runtime behavior is. Make sure you cache your results as much as possible, eliminate unnecessary DB calls. On the sysadmin side, assuming your app is PHP the following is mandatory: make sure you're using PHP-FPM, and enable APC or Opcache. Optionally, consider installing Memcached and start using it from the app to cache data that is expensive to generate. If you're running on Apache, switch to Nginx. Finally: reverse proxy service. They'll filter out most malicious requests for you. When the day comes where you experience a real attack, you'll have no chance of keeping the server up without using such a service.

joelcollinsdc 13y ago

> If request rates like these bring your site down, you have a serious software problem. Either that or you chose a CMS to host your website (Drupal Commerce?). 50-100 uncached application requests/sec is pretty high for a larger (in terms of number of contributed modules) drupal site