Комментарии 55
НЛО прилетело и опубликовало эту надпись здесь
В современном интернете — ЧПУ стандарт де-факто
На счет 444 — почему нагрузка меньше? Не все равно, что отдавать?
На счет 444 — почему нагрузка меньше? Не все равно, что отдавать?
0
НЛО прилетело и опубликовало эту надпись здесь
В мемориз, однозначно.
+2
https://calomel.org/nginx.html Читайте главу 'IMPORTANT NOTE: Why are we using the error code «return 444» ?'
0
ну это всегда можно уточнить, стоит или нет.
0
Присоединяюсь к 444, сам хотел написать.
Грубо говоря, всё остальное — сервер оправдывается, почему он не можут дать конент (нет на сайте, ушло, запрещено).
А 444 — просто нет и всё. Т.е. сервер молчит, пользователя в игнор.
Грубо говоря, всё остальное — сервер оправдывается, почему он не можут дать конент (нет на сайте, ушло, запрещено).
А 444 — просто нет и всё. Т.е. сервер молчит, пользователя в игнор.
+3
Скажите, а это правило разве не отключит вообще возможность передавать параметры GET-запросом? )
+5
Можно же дописать только для определённой части сайта.
0
На момент атаки это меньше всего беспокоит. Когда боты попадут в лог и будут забанены — все вернется как и было.
+2
Скажите, вот есть список ип ботов, как и чем лучше банить?
0
Так… это… фейсбук вечно пытается пристроить свой параметр, гуглоаналитика тоже.
+2
В 6ом друпале иногда нужны урлы с вопросом, даже когда включены урлы.
Алсо ЧПУ = Числовое программное управление. Долго курил как может быть с ним сервер.
Алсо ЧПУ = Числовое программное управление. Долго курил как может быть с ним сервер.
+2
НЛО прилетело и опубликовало эту надпись здесь
ЧПУ также «Человекопонятный урл» 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
0
GET'ы нужны даже при наличии ЧПУ. Например для пагинаторов или поиска.
+1
«Пагинаторы» Без проблем работают в Wordpress к примеру, Не вижу проблемы. А вот поиск — согласен. Хотя если отрубать аргументы только при атаке, то оправдано, так как не до поиска будет, а лишь бы выстоять.
0
Как будто кто-то мешает вести атаки на адреса типа /foo/bar/13245
+5
Ботам невыгодно делать такое, т.к. при настроящем foo.php/foo/bar часто может выскакивать ошибка 404.
0
и что? почему это не выгодно?
0
Если папки /foo/bar/123 не существует, то посетители — зомби будут просить 404 страницы, которые не жрут много ресурсов, а значит не создадут высокой нагрузки. Особенно если во время атаки правильно подкрутить nginx. Это не на всех сайтах, но на многих.
Сравните две ссылки:
habrahabr.ru/foo/bar/123123/
habrahabr.ru/?=foobar=123123
Какая более нагружает сервер — очевидно.
Сравните две ссылки:
habrahabr.ru/foo/bar/123123/
habrahabr.ru/?=foobar=123123
Какая более нагружает сервер — очевидно.
0
Все пришедшие с контекстной рекламы тоже попадут под нож…
?from=google
?from=dir
и т.п.
?from=google
?from=dir
и т.п.
+11
nginx поддерживает регулярки, так вот, чтобы не нароком не забанить валидных юзеров, лучше использовать регулярку которая выявляет рандомный URL.
+1
А можно ли выделить список аргументов, которые должны пропускаться?
Если урлы преобразованы через htaccess c i.php?h=h.jpg -> /i/hjpg
эти урлы тоже будут резаться этим правилом?
Если урлы преобразованы через htaccess c i.php?h=h.jpg -> /i/hjpg
эти урлы тоже будут резаться этим правилом?
0
Да, т.к. nginx работает до apache.
Такие преобразования стоит выкинуть, и статику (/i/h.jpg) отдавать nginx-ом. Но если у Вас много денег и 2 теребайта оперативной памяти, то необязательно.
Такие преобразования стоит выкинуть, и статику (/i/h.jpg) отдавать nginx-ом. Но если у Вас много денег и 2 теребайта оперативной памяти, то необязательно.
0
Насколько я понимаю, данный метод добавления мусора эффективен когда на сервере кэшируются страницы по ключу URL. Таким образом, кэш очень быстро забивается и сайт падает.
+2
Самое полезное в этой статье я узнал из коментов. Про код 444 =)
а обрезать всех кто с аргументами, это такая временная мера дабы главная страница работала несмотря на ддос.
а обрезать всех кто с аргументами, это такая временная мера дабы главная страница работала несмотря на ддос.
+15
Парсите access_log-и и в случае необходимости на стороне nginx выдавайте captcha
0
а как же отслеживание кампаний googe_analytics, контекстная реклама итп?
0
тип ботнета не новый.
рассчет атакующих понятен — пробить кэши.
бьется вполне просто и прозрачно стандартными приемами с анализом поведения.
рассчет атакующих понятен — пробить кэши.
бьется вполне просто и прозрачно стандартными приемами с анализом поведения.
0
Интересное решение, (write on brain)
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
>ЧПУ сейчас является стандартом де-факто
microformats.org/wiki/rest/urls — обратите внимание на эмуляцию методов PUT и DELETE в браузерах
Конечно, всё зависит от ресурса, но в некоторых случаях важнее, чтобы отправленный и дошедший до сервера клиентский запрос был обработан, пускай и ответа на него не будет.
microformats.org/wiki/rest/urls — обратите внимание на эмуляцию методов PUT и DELETE в браузерах
Конечно, всё зависит от ресурса, но в некоторых случаях важнее, чтобы отправленный и дошедший до сервера клиентский запрос был обработан, пускай и ответа на него не будет.
0
надо бы ещё отделять внутренние подзапросы. они часто с "?".
0
Используйте регекспы. У меня был подобный ддос, лечил правилом
##
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;
}
##
+1
количество запросов на секунду не спасет?
limit_req_zone $binary_remote_addr zone=one:20m rate=5r/s;
Ваше решение выглядит — как из пушки по воробьям по моему…
limit_req_zone $binary_remote_addr zone=one:20m rate=5r/s;
Ваше решение выглядит — как из пушки по воробьям по моему…
-1
Спасибо!.. спасло… :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита от DDOS атаки случайными аргументами при помощи Nginx