Комментарии 33
4000 запросов за час? Это и близко не ddos, я столько от обычных клиентов получаю иногда
Bingbot'а за что забанили?
Скачиваем актуальные БД с IP адресами:
По указанной ссылке скачивается база MaxMind, а он запретил использовать свои базы в России с 25 апреля
Ну так-то и PetalBot тоже является поисковым ботом huawei, но как показала практика, частенько с этих юзерагентов валится какое-то подозрительно высокое количество запросов..
Ну и в любом случае все упомянутые боты вроде соблюдают правила из robots.txt, так что достаточно было бы просто туда соответствующие User-agent и Disallow прописать да и всё
UserAgent - это просто текстовое значение, которое передаётся с запросом.
В чем проблема прикрутить UserAgent публичных ботов к ботнету и ловить профиты с пропуска траффика помеченого как "безопасный" ?
В том, что вышеупомянутые боты добросовестные и так не делают
Ааа-а-а, ну так это же в корне меняет дело!
Черт, Ваш план просто гениален. Надежен как швейцарские часы.
У меня вот есть свидетельства, как после добавления запрещающих правил в robots.txt поток запросов от ботов резко уменьшился, могу вам свои access-логи погрепать
Ну, это с одного IP адреса, но да, как-то мало. Скорее всего сами и устроили, чтобы в статью графики вставить. Ну ок, что уж тут такого). Важно ещё учитывать, что за сайт. Я не удивлюсь, если окажется, что за 5 мин, которые я таскаю, правлю и т. д. задачки по Jira я накручиваю примерно такое кол-во запросов (вот купит Маск джиру...).
А вообще да, там вон Azure уже в 2021 году отразил атаку 340 000 000 RPS. Длился праздник не долго - у хакеров тоже, знаете, не бесконечность денег, но вот это можно назвать серьёзной DDoS атакой.
Так там и нет утверждений, что это ddos . Фраза "одним из отличительных признаков" я думаю прекрасно говорит об этом. Если у вас достаточно большое количество легитимного трафика поступает от пользователей и вы прекрасно знаете об этом, я думаю логика сравнительного анализа информации из логов на основании предыдущего интервала времени поможет вам в любом случае вычленить вредоносный IP, делать подобные выводы можно лишь на основе совокупности факторов, которые также прекрасно описаны выше.
4000 запросов за час? Это и близко не ddos, я столько от обычных клиентов получаю иногда
Прежде чем утверждать какую-либо информацию необходимо проверить со своей стороны можете ли вы осуществить скачивание базы по указанной ссылке. При проверке на текущий момент я не фиксирую каких-либо проблем. Но даже если они у вас и есть, я думаю вы можете прекрасно ознакомиться со статьями про VPN, которых за последнее время появилось не мало.
По указанной ссылке скачивается база MaxMind, а он запретил использовать свои базы в России с 25 апреля
можете ли вы осуществить скачивание базы по указанной ссылке
Если могу технически - это ещё не значит, что могу по закону. Успешно скачанная в Россию база по указанной ссылке автоматически нарушает лицензионное соглашение MaxMind (и отсутствие текста этого соглашения, приложенного к ссылке, - тоже нарушение)
Немного проясню: в текущем тексте соглашения Россия не упоминается (забыли добавить?), но в апреле MaxMind разослал российским аккаунтам письма счастья о том, что они присоединяются к санкциям и отбирают доступ, руководствуясь пунктом 10 этого соглашения
Там есть и другие интересные пункты, например пункт 6c требует регулярно скачивать обновления, удалять старые версии базы да ещё и письменно уведомлять MaxMind о проведённом удалении по их запросу
Возможно, вместо MaxMind стоит попробовать какой-нибудь DB-IP Lite, у которого лицензия — чистый Creative Commons без дополнительных условий (но у меня попробовать пока руки не дошли)
Из всего описанного, упоминания достойно только использование GeoIP в виду последних событий, и разумеется fail2ban, крайне вскользь упомянут iptables (у него вроде есть более современный аналог, применяемый ныне), про который стоило сказать гораздо больше.
Использование rate - вредная опция, так как в случае, если на 1 страницу приходится статики типа img, js, css помимо html больше чем указан лимит, ресурсы не будут получены. Как результат, реальный пользователь получит криво работающий сайт. Нужно либо постоянно держать в голове число из лимита, либо намеренно указывать его с запасом.
статику вообще надо из rate исключать(или другой лимит ставить)
Просто вы не умеете это готовить. Можно нормально настроить Rate и проблем не будет.
разделить на location, для каждого location свой rate limit. + использовать burst для легитима, который равен значению контента который запрашивается вместе со страницей, ну и директива nodelay, или delay в помощь для шейпинга.
/ 2r/s + burst + delay=3
/css/ 10r/s + burst + nodelay
/images/ 20r/s + burst + nodelay
Какая-то детская защита от ддос для локалхоста.
Если это не сайт-открытка, а, например, сайт с апи, то блокировка по гео просто парализует работу. Сейчас многие в облаках, и гео будет скорее вредной, если клиент в каком-нибудь AWS. Если сайт и апи разделены, то наличие гео блока для сайта еще норм.
Для нормального сайта, с хорошей посещаемостью, даже при 1000-2000rps, легко получить много запросов с одного IP через мобильных провайдеров. Так что rate limit тоже вариант такой себе.
Не надо делать if с перечислением, сделай лучше map. Когда надо будет добавить 16,17,... агент, задолбаешься проверять, есть ли такой уже в списке.
Если уж блокировать страны, то почему бы не делать это через iptables? Неужели так нравятся 10 гиговые логи nginx?
Если бы так легко было защититься от ддос, его бы уже не существовало. И уж тем более не существовало бы платных решений, типа ddos-guard.
Данная статья более подходит не для крупных проектов. На своём опыте могу поделиться, что многие страдают проблемой нагрузки сервера от большого количества поисковых ботов. Для проекта их уровня на данный момент нет смысла покупать платные решения. Остаются лишь варианты создания уровней блокировки трафика своими силами, не каждая площадка в интернете имеет 1000-2000rps.
Для нормального сайта, с хорошей посещаемостью, даже при 1000-2000rps, легко получить много запросов с одного IP через мобильных провайдеров. Так что rate limit тоже вариант такой себе.
Данный способ показан лишь как один из вариантов реализации, как вы его осуществите уже зависит от вас.
Не надо делать if с перечислением, сделай лучше map. Когда надо будет добавить 16,17,... агент, задолбаешься проверять, есть ли такой уже в списке.
Если вас так пугают крупные логи, то вам поможет настройка ротации логов.
Если уж блокировать страны, то почему бы не делать это через iptables? Неужели так нравятся 10 гиговые логи nginx?
На ваш детский проект пришел поток трафика > 1Gbps, все ваши танцы бесполезны - у вас забит канал.
Если хотелось написать статью то не называйте ее "защититься от DDoS" у вас мануал rate-limit для приложения на бекенде
Дело в том что хостеры часто предлагают защиту L3/L4, а вот L7 не предлагают.
Так что это имеет смысл в такой конфигурации когда хостер обеспечивает защиту L3/L4.
Почему забит, при блокировке, IP будет забанен на уровне Firewall, TCP просто будет дропаться. И хостер если предоставляет защиту L3\4 будет уже блочить такие IP как TCP syn flood.
Хостер кстати может вообще вырубить виртуалку чтобы не было влияния на остальные хосты, так делает DO.
1) limit_req_zone $binary_remote_addr zone=shield:10m rate=10r/s;
2)rate=10r/s /// количество requests в секунду, в данном случае 10 запросов в секунду
3) Отсюда мы видим, 1 запрос получил 200-й код ответа, после чего все остальные запросы получали 503-й код, говорящий о том, что сервер не готов обработать данный запрос. Прекрасно — мы на верном пути.
Не могли бы вы пояснить логику? Из написанного в пунктах 1 и 2 ожидаешь, что 10 запросов можно отправлять, и «отлуп» начнется с 11 запроса.
Да вы правы, спасибо. Данный момент был упущен. Скорректировали.
Не совсем так. У NGINX окно одна миллисекунда.
10r/s это не 10 RPS, а не чаще 1 запроса в течении 100ms. Насколько я понимаю если прилетит два запроса в течении 100мс, то второй отбросит кодом 503.
Так как обычно загружается корень сайта и контент на нем, это всплеск из 20-30 ресурсов если они лежат в корне сайта. И часть контента отрежет, так как они будут запрошены единовременно, чаще чем 1 за 100ms. чтобы этого не было нужно пользоваться директивой burst=X , с ней запросы с ней запросы будут обрабатываться со скоростью 1 запрос в 100 секунд. Если в течении 1 секунды прилетело больше 10 запросов , X запросов будет поставлено в очередь, и обрабатываться со скоростью 10/rs, все что больше числа X, будет отброшено. Так можно шейпить трафик.
Есть еще директива nodelay, она позволяет обрабатывать всплески без задержек, но тогда нужно больше ресурсов у фронта.
| awk '{print $1}'|
Это какой-то оверкилл. Для вырезания первой колонки по разделителю-пробелу есть:
| cut -d ' ' -f 1 |
А в чём "оверкилл"?)
Скорее всего, тут оверкилла не будет, потому что и с cut'ом, и без него, данные tail'ом/head'ом загоняются в память, и оттуда уже обрезаются. Кому-то cut кажется семантически более подходящим, кому-то больше нравится awk за его универсальность.
А вот если бы анализировали весь файл, можно было бы запустить awk прямо на нём (awk '{print $1}' access.log), и тогда awk уделал бы cut по всем фронтам безоговорочно.
nginx все-таки настоятельно рекомендует не if, а map. можете прокомментировать, почему был выбран if?
Уже писал выше, что это лишь один из вариантов реализации. Никто не запрещает его использовать как и применять map.
Для локейшн контекста авторы фактически запрещают. Или для вас запрет это только когда технически невозможно?
Копируем стандартный jail.conf и сохраняем его в jail.local:
Просто создаем такой файл, копировать в него содержимое стандартного совершенно не зачем.
logpath = /var/log/nginx/*error.log
Так себе идея для реального проекта с несколькими файлами логов.
Лучше все же указывать конкретный файл.
Как защититься от dos/ddos, или Как я начал вновь высыпаться по ночам