следующая история про неудавшийся ддос.
В рамках подготовки к задаче по переносу обработки картинок на другой сервер (см предыдущий пост), надо было стереть кэш memcached. Раньше это было достаточно болезненно, ибо mysql захлёбывался от количества запросов. Но сейчас мемкэшов стало два и можно было перегружать их по одному - удаляя по половине кэша. Таким образом нагрузка была меньше.
Ну встал пораньше и в 10 утра перегрузил по очереди кэши. Вроде всё хорошо с первым пиком сервера успешно справились. Дальше нагрузка всё равно немного больше - процентов на 20%. Они пару дней будут наполняться менее популярными страницами, куда заходят, но не часто.
Через пару часов проверяю нагрузку. Обнаруживаю что она выше, чем должна быть. Первая мысть - где-то напортачил с кэшами и они не подцепились. Тогда ещё через час сервера умрут по естественной нагрузкой. Смотрю запросы в мускуле - и вправду, идёт много запросов, которые должны быть жёстко закэшированны. И тут же понимаю, что если бы кэши полностью не подцепились, то сервера бы уже умерли. А тут скоро уже пиковая нагрузка, а им вполне нормально, хоть и выше нормы.
Долго размышляю и изучаю данную проблему. На всякий случай, перегружаю апачи. Ничего не меняется. Иду мыться в душ и там меня осеняет. Симфони (да и большниство серверов) не кэшируют POST-запросы. Наверное где-то есть страница, которая грузится через POST. Возвращаюсь и обнаруживаю в логах примерно такое:
85.26.241.3 - - [30/Jan/2013:05:09:14 +0100] "POST /tag/mass%2Beffect/new/11?count=&1359518948806.76 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
85.26.241.3 - - [30/Jan/2013:05:13:38 +0100] "POST /post/204783?count=&1359519213127.96 HTTP/1.1" 499 0 "http://ads.heias.com/x/heias_sc.swf" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" "-"
В гугле находит, что heias - это какая-то адвара. Похоже ещё и система управление ддосом. Они слали специально запросы, которые пробиывают кэш. Проверка на тип запроса у меня не везде проводилась и в некоторых местах оно пробивалось. Правда результат был всё равно плачевный для них - если бы я не мониторил специально нагрузку, то никто бы и не заметил этого ддоса. Им надо было создать хотя бы 20% от естественной посещалки реактора, чтобы пробивка кэша дала результаты.
Сейчас погрепал в логах - они нашли ещё пару мест, где не проверяется GET/POST. Надо будет поправить для чистоты кода.
MOAR ИСТОРИЙ
попробуй fail2ban в связке со скриптом авто отправки сообщений хостерам https://github.com/Ajex/AntiDdosAbuse
А post вообще бы заблочил везде, кроме как отправку картинок.
А post вообще бы заблочил везде, кроме как отправку картинок.
да, fail2ban итак используется. А вот отравка сообщений хостерам - это хороший скрипт. Давно думал где бы взять его - спасибо за ссылку =).
а post всё же лучше использовать для всех запросов, напрямую изменяющих состояние сайта. И в таких запросах надо отвечать редиректом на страницу
а post всё же лучше использовать для всех запросов, напрямую изменяющих состояние сайта. И в таких запросах надо отвечать редиректом на страницу
По поводу post, строго говоря ты прав, но кругом аякс, вебсокеты, кому они нужны те правила.
Сейчас js отключен у такого малого числа людей, что проще им сказать - включите или ГТФО., а страницу отдавать в виде json+template
Сейчас js отключен у такого малого числа людей, что проще им сказать - включите или ГТФО., а страницу отдавать в виде json+template
нет никакой проблемы аяксом слать post-запросы. И это вроде порописано как рекомендация в спецификации по http
За пост - спасибо, поучительно.
А какая симфоня используется, кстате?
А какая симфоня используется, кстате?
первая. На момент создания мудактора 2ой ещё не существовало
А, ну да, логично.
Сильно отличатся? Я только со второй работал, и она хороша.
Сильно отличатся? Я только со второй работал, и она хороша.
2ая сильно лучше первой
Чтобы написать коммент, необходимо залогиниться