Какие можете предложить проверенные Вами решения для данной задачи? iptables хорош, но нужна автоматизация.
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
iptables + ipset. (ipset уже включили в офиц ветку ядра).
И против кого работать будем? — против школоты. Нужно решение мощнее.
Гм, мощнее не совсем понял… И при чем знесь школота? Ну хотите — TARPIT чтобы удаленным системам как можно «слаже» пришлось…
да, и смотря что защищать. Вот, например, на apache есть такая штука как evasive — модуль который детектит атаку и может «рассказать» об этом фаеру, роутеру, кому надо вобщем…
на сегодня хочу защитить веб. evasive не работает если атаки идут с разных IP-адресов, он думает что это пользователи.
Если вас атакует не школота, то iptables не поможет, магистральный пров тупо обрежет вам интернет, поскольку гигабиты в секунду трафика положат все шлюзы этого провайдера.
Но это так, к слову пришлось. А вообще, вы в состоянии измыслить алгоритм отличения нормального пользователя от DDoS’ера? Это не всегда возможно, но почему-то мне кажется, что такой неудачный расклад выпал не вам, и значит алгоритм измыслить можно… Ну дык измысльте, закодьте на PHP (или что вы там используете на server-side?) и воткните в каждый php файл вызов этого алгоритма, который будет вычислять DDoS’еров, и оповещать iptables об их ip адресах.
Что именно стоит писать в iptables об этих адресах — это уже зависит от характера атаки. Если атакующих хостов много-много, то я думаю вряд ли придумается что-то лучше, чем DROP. А если их не так уж и много, но каждый из них много-много запросов в секунду шлёт, то можно им и подгадить… ;)
Да, я понимаю, решение «наколеночное», но у таких решений есть один огроменный плюс: они легче всего подстраиваются под постоянно изменяющиеся условия.
Если бы это была школота, она бы ддосила из своих ипишников, ну или чета мелкое. Тут побольше запросов и с разных А-подсетей.
Насчет провайдера можно не волноваться, в случае гигабитного трафика — отправляем в нулл к тому же провайдеру, возможность есть.
И к алгоритму — плачевно но влип я. Да можно было бы детский скриптик наваять на ПХП, который проверяет дддосер или не ддосер, вот тут возможность отпадает. Скрипты я трогать не имею право, как собственно и подгадить им.
хостов нормально, неделю назад решилась проблема так:
теперь ребята из разных А ддосят, точнее флудят.
ЗЫ: возможно упростит задачу запросы идут такие GET / HTTP 1.0, из 1000 запросов, но 3 из них — реальные клиенты.
То есть DDoS’еры используют HTTP1.0, но 0.3% всех HTTP1.0-запросов всё же легитимны?
Нет, ну и всё же, алгоритм распознавания есть? Такой чтоб 100% можно было отсеивать кого-то? Если есть, то ты выпиши его сюда. Можно по-русски, не обязательно пользоваться языками типа PHP или C. Тогда можно будет искать инструментарий, который позволит согласно этому алгоритму метелить DDoS’еров.
Вообще, задача решаемая крайне сложно. Я наблюдал и участвовал (увы, лишь советами) в решении подобных проблем на ксакепе. Банить подсетями нельзя. По ip банить тоже не всегда можно, поскольку огромное количество народа сидит за NAT’ом, и запросто за таким NAT’ом может сидеть также и зомбированный комп. Соответственно забанив по ip зомби, забаним и грядку (может быть тысячи) потенциальных легитимных пользователей. Я многадумал тогда, и пришёл к выводу, что DDoS непобедим, единственное что можно сотворить — это максимально замедлить ботов, при этом по-минимуму зацепив этим замедлением легитимных пользователей. Но это канает только если сервер не справляется с DDoS из-за нехватки мощностей — процессоров маловато, или СУБД не справлятся, или ещё что-то.
И если так, то можно попробовать пересилить DDoS. Простейшие и наиболее естественные меры — прикрыть апач nginx’ом и отдавать весь статический контент через nginx. Настроить кеширование на nginx. Чтобы максимум запросов обрабатывалось бы nginx’ом без участия апача.
Кстати тут возникает следующий вопрос: чем именно мешает этот DDoS? Я могу раскрыть этот вопрос целым фонтаном вопросов. DDoS жрёт слишком много трафика? Не хватает мощности железа? Если железо слабое, то где узкое место? Процессор? Жёсткие диски? Что именно тормозит? Ядро, апач на пхп-скриптах, СУБД?
Ведь может быть, всего-то что надо — это напинать по яйцам веб-девелоперов, чтобы они оптимизировали работу с СУБД. А может надо ногою распахнуть дверь в кабинет директора, войти, стукнуть кулаком по столу, и потребовать новую железку под содержание сервера.
какг-бе если просмотреть http-status, и через секунду обновить можно увидеть такое
через секунду
т.е. понятно что это человек, Ддосеры же постоянно GET / HTTP 1.0.
Nginx`ом прикрыта статика. Если перевесить Nginx на статическую страницу (А-ля сайт закрыт), то серву по барабану ДДос. Но вешаем только на динамику — через часика два сервер в глубоком небытие, приходится ремоут ребутом пользоваться. И ДДос мешает зависанием самого апача. Железо… Делка Р710-я, т.е. ни проц ни сас диски ни оператива.
Скрипты обрабатываются раз в минуту по такому принцыпу (bash):
ловим 10 000 пакетов tcpdump по порту 80, считаем кол-во повторяемых ипишников, если более 1000 — гоним парится. Это работало неделю назад, теперь ребята поняли систему, пошли поумнее — не дают эти 1000 пакетов собрать, даже 200 нету.
Насчет подсети — да неверно, но это единственное решение которое помогло 100% на хороший срок.
А скрипты… DLE, wordpress.
HTTP/1.0 — я даже не могу вспомнить какие браузеры до сих пор пользуются 1.1. Разве-что проксики. Но тогда (если не «высокоанонимный») есть X-Forwarded-For. Вот, например на меня недавно напал робот DigExt DTS Agent. Но тут было просто — он представлялся в User-Agent. По нему в таблах и заблокировал:
-A ban_bots -p tcp -m string --string «DigExt; DTS Agent» --algo kmp -j DROP
Можно отбрасывать весть HTTP/1.0 трафик в случае если нету X-Forwarded-For.
Если идёт DDoS, то вряд ли в качестве клиента выступает браузер. Скорее какая-то наколенная поделка, которая вполне может ходить и через HTTP/1.0
Об том собственно и речь. Что в большинстве случаев — это паразитный трафик..
Что в свою очередь чревато материальными последствиями =(
отлично, но то браузера разные, от 9 оперы, до новейшого хрома.
Постараюсь кратко изложить основные принципы, как мне это видится.
Здесь мы говорим не о «вообще DDoS» а о «HTTP DDoS». При чем таком, которому далеко до заваливания канала и с которым легко справляется Nginx на статике.
Вот основные вещи, на которых все базируется:
Такую систему легко можно собрать на коленках, для этого потребуются:
Анти DDoS морда (далее Морда), это (тезисно):
Скрипт пополняющий iptables, это:
Примерный алгоритм работы системы:
Итого получилось, что мы разбили нагрузку так:
Такой штукой мы отбивали DDoS ~10-15 000 в секунду с ботнета примерно в 150 000 узлов. DDoS прошел через 2 дня, поняли что бестолку.
Если надо — можем настроить, (495) 725-17-47, Дмитрий ;).
я же више писал:
1. Я не имею право свою морду высовывать в папку ВЕБ.
2. Лимитировать кол-во запросов тоже нет смысла, разные СЕТИ, не то что бы ИПишники.
3. зачем так сложно? все можно было решить iplimit, и не прибегая к капчам и хедерам.
PS: решения вида «наваять на PHP/Python/perl на вебе» сразу отпадают, также и отпадает iptables`ами закрывать стринг «GET / HTTP 1.0» (втречал и такой бред в рунете ). Лимитить по подсетям тоже не выход.
PS1: пока кручу в сторону snort (snort.org), только туговато с ним.
Морда стоит отдельно, может стоять вообще на отдельном сервере. Остальное делает Nginx. Вы, видимо, не до конца поняли как это работает.
Лимитировать кол-во запросов смысл есть. И это не лимит, а лимит после которого надо «подтвердить», что ты реальный пользователь. Про разные сети и ипишники — я говорил, что у нас получилось отбить DDoS с примерно 150 000 узлов такой штукой.
iplimit бред, так как не позволяет отличить пользователя от бота.
Разумеется, что кроме лимитирования кол-ва запросов в той самой Морде можно, выявив общие особенности между запросами ботов, фильтровать еще и по ним.
Я описал наш реальный опыт защиты от такого DDoS.
Разумеется ваша конкретная ситуация требует какой-то трансформации метода, но в общем и целом описанная система является хорошей стартовой площадкой для наращивания дальнейшего функционала. Nginx может обрабатывать до 10К запросов в секунду, вот это предел для таких систем.
Способ возможно Вам и помог. Но использовать капчу… Как объяснить владельцу атакуемого сайта, что у него перед входом на его сайт светится капча? Если он толком ДДос от ДОС отличить не может… будет проблема.
Тут стоит понимать, что в таком деле всегда важнее всего критерии, по которым отличаем пользователей от ботов. Чем лучше критерии тем меньше пользователей видят капчу. При этом капча в 1000 раз лучше, чем бан по iptables.
либо я чего-то не понимаю, либо данное решение нам не поможет. Как решение может помочь если ДДОС, и посетители С РАЗНЫХ А-ПОДСЕТЕЙ?
Два. Вебморда — уже не статика, а значит уже тут будет апач вешаться, тогда смысл от нёё?
Да, с разных подсетей. С тысяч разных подсетей. Именно такой случай у нас и был.
Морда — это не статика, но ее можно сделать очень быстрой. Очень-очень-очень быстрой:
На виртуалке с 2-мя ядрами (4 треда) от E5530 наша версия справляется с ~2 500 запросами в секунду. При размере морды в ~4Кб это чуть менее 80 Мбит/с.
Если по каким-то причинам 2500/с мало — могу предложить сделать морду на Си++. Boost Asio + собственный парсер HTTP у меня на ноутбуке (T9300) может ответить на ~8000 запросов в секунду, значит на нормальном сервере эта цифра будет раза в два больше… В общем тут надо исходить от задач. Еще можно морду воткнуть на нескольких серверах, Nginx умеет редундить, как все помнят.
На такую систему никто не согласен. Увы.
ЗЫ: 53 портик вебом не прикроешь.