Comments 55
В современном интернете — ЧПУ стандарт де-факто
На счет 444 — почему нагрузка меньше? Не все равно, что отдавать?
На счет 444 — почему нагрузка меньше? Не все равно, что отдавать?
В мемориз, однозначно.
https://calomel.org/nginx.html Читайте главу 'IMPORTANT NOTE: Why are we using the error code «return 444» ?'
ну это всегда можно уточнить, стоит или нет.
Присоединяюсь к 444, сам хотел написать.
Грубо говоря, всё остальное — сервер оправдывается, почему он не можут дать конент (нет на сайте, ушло, запрещено).
А 444 — просто нет и всё. Т.е. сервер молчит, пользователя в игнор.
Грубо говоря, всё остальное — сервер оправдывается, почему он не можут дать конент (нет на сайте, ушло, запрещено).
А 444 — просто нет и всё. Т.е. сервер молчит, пользователя в игнор.
Скажите, а это правило разве не отключит вообще возможность передавать параметры GET-запросом? )
Можно же дописать только для определённой части сайта.
На момент атаки это меньше всего беспокоит. Когда боты попадут в лог и будут забанены — все вернется как и было.
В 6ом друпале иногда нужны урлы с вопросом, даже когда включены урлы.
Алсо ЧПУ = Числовое программное управление. Долго курил как может быть с ним сервер.
Алсо ЧПУ = Числовое программное управление. Долго курил как может быть с ним сервер.
ЧПУ также «Человекопонятный урл» ru.wikipedia.org/wiki/%D0%A7%D0%9F%D0%A3_%28%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82%29
GET'ы нужны даже при наличии ЧПУ. Например для пагинаторов или поиска.
«Пагинаторы» Без проблем работают в Wordpress к примеру, Не вижу проблемы. А вот поиск — согласен. Хотя если отрубать аргументы только при атаке, то оправдано, так как не до поиска будет, а лишь бы выстоять.
Как будто кто-то мешает вести атаки на адреса типа /foo/bar/13245
Ботам невыгодно делать такое, т.к. при настроящем foo.php/foo/bar часто может выскакивать ошибка 404.
и что? почему это не выгодно?
Если папки /foo/bar/123 не существует, то посетители — зомби будут просить 404 страницы, которые не жрут много ресурсов, а значит не создадут высокой нагрузки. Особенно если во время атаки правильно подкрутить nginx. Это не на всех сайтах, но на многих.
Сравните две ссылки:
habrahabr.ru/foo/bar/123123/
habrahabr.ru/?=foobar=123123
Какая более нагружает сервер — очевидно.
Сравните две ссылки:
habrahabr.ru/foo/bar/123123/
habrahabr.ru/?=foobar=123123
Какая более нагружает сервер — очевидно.
Все пришедшие с контекстной рекламы тоже попадут под нож…
?from=google
?from=dir
и т.п.
?from=google
?from=dir
и т.п.
nginx поддерживает регулярки, так вот, чтобы не нароком не забанить валидных юзеров, лучше использовать регулярку которая выявляет рандомный URL.
А можно ли выделить список аргументов, которые должны пропускаться?
Если урлы преобразованы через htaccess c i.php?h=h.jpg -> /i/hjpg
эти урлы тоже будут резаться этим правилом?
Если урлы преобразованы через htaccess c i.php?h=h.jpg -> /i/hjpg
эти урлы тоже будут резаться этим правилом?
Насколько я понимаю, данный метод добавления мусора эффективен когда на сервере кэшируются страницы по ключу URL. Таким образом, кэш очень быстро забивается и сайт падает.
Самое полезное в этой статье я узнал из коментов. Про код 444 =)
а обрезать всех кто с аргументами, это такая временная мера дабы главная страница работала несмотря на ддос.
а обрезать всех кто с аргументами, это такая временная мера дабы главная страница работала несмотря на ддос.
Парсите access_log-и и в случае необходимости на стороне nginx выдавайте captcha
а как же отслеживание кампаний googe_analytics, контекстная реклама итп?
тип ботнета не новый.
рассчет атакующих понятен — пробить кэши.
бьется вполне просто и прозрачно стандартными приемами с анализом поведения.
рассчет атакующих понятен — пробить кэши.
бьется вполне просто и прозрачно стандартными приемами с анализом поведения.
Интересное решение, (write on brain)
>ЧПУ сейчас является стандартом де-факто
microformats.org/wiki/rest/urls — обратите внимание на эмуляцию методов PUT и DELETE в браузерах
Конечно, всё зависит от ресурса, но в некоторых случаях важнее, чтобы отправленный и дошедший до сервера клиентский запрос был обработан, пускай и ответа на него не будет.
microformats.org/wiki/rest/urls — обратите внимание на эмуляцию методов PUT и DELETE в браузерах
Конечно, всё зависит от ресурса, но в некоторых случаях важнее, чтобы отправленный и дошедший до сервера клиентский запрос был обработан, пускай и ответа на него не будет.
надо бы ещё отделять внутренние подзапросы. они часто с "?".
Используйте регекспы. У меня был подобный ддос, лечил правилом
##
if ($query_string ~ "\w+\d+=\d+") {
access_log /opt/www/temp/log/nigerz;
return 444; break;
}
##
##
if ($query_string ~ "\w+\d+=\d+") {
access_log /opt/www/temp/log/nigerz;
return 444; break;
}
##
количество запросов на секунду не спасет?
limit_req_zone $binary_remote_addr zone=one:20m rate=5r/s;
Ваше решение выглядит — как из пушки по воробьям по моему…
limit_req_zone $binary_remote_addr zone=one:20m rate=5r/s;
Ваше решение выглядит — как из пушки по воробьям по моему…
Спасибо!.. спасло… :)
Sign up to leave a comment.
Защита от DDOS атаки случайными аргументами при помощи Nginx