Pull to refresh

Comments 61

А мне всегда казалось, что сильно долбить с малого кол-ва адресов глупо и надо долбить понемногу, но с большого кол-ва машин…
Я тоже так раньше думал. Но когда столкнулся с тем, что сервер долбили кроме стандартных ботов, несколько таких, которые выдавали до 400 тыс pps и поток в 200-300 мегабит каждый. Фишка в том, что на обычных сетевых, кои стоят в большинстве серверов, прерывания обрабатываются одним ядром, в независимости от их кол-ва на машине. И от такого числа коннектов, даже при полном DROP всех соединений вся сетевая подсистема уходит в астрал. Ну и затык канала тоже ни кто не отменял, особенно если он у вас небольшой.
Бороться с таким достаточно проблематично. Вот абузами такие дедики убиваются достаточно просто (когда как, иногда конечно приходилось звонить и ругаться). Собственно для этого и затевалась вся затея с этими скриптами, но потом я применил ее отослав абузы по нескольким сотням адресов из списка тех ботов что нас долбили постоянно, заметил, их поубавилось, а на ящик стали приходить письма мол спасибо проверим, или спасибо отослали уведомление клиенту.
И такое всё, чаще и чаще, ибо рутануть мажорный сервер, у каких-нибудь дизайнеров, офисных сисадминов и иже с ними «компетентных» товарищей, гораздо проще и доступней юным кул хачикам, чем создание и управление ядрёным ботнетом. А эффективность, вполне себе хороша, хоть и временна.
Эффективность очень уж временна. Такой поток от хостящегося сервера «дизайнеров» провайдер по идее поймает в автоматическом режиме за буквально пару минут.
Интересное решение, но какое-то не красивое.
Это всё-равно что вас в детском садике толкнул кто-то, а вы к воспитателю: «А он толкнул меня, вот запись камеры, накажите его». Да, возможно эффективно, но не красиво.
А вот если вы просто заблокируете, к примеру, пакеты от этого IP или ещё чего-нибудь, то атакующий будет знать, что тут работает «сильный админ».
Если бы мне пришло такое письмо от провайдера, то я бы даже захотел вместо установки антивируса специально продолжить DDoS.
Кстати, как поведёт себя ваша система если я буду слать запросы со случайного IP?
Интересная у вас терминология, «случайный IP»?
UFO just landed and posted this here
Имелся ввиду «фиктивный» IP, сгенерированный «случайным» образом.
Я в первую очередь подумал о динамическом IP, когда адрес выдаётся достаточно часто. Но провайдеры в таких случаях могут просмотреть логи и узнать кто в конкретный момент времени пользовался указанным в письме адресом.

По повод вашего варианта, для меня это выглядит странно и я хотел бы усомниться в возможности проведения такой атаки. Я конечно слышал о дырах, которые заключаются в недостаточной фильтрации IP-адреса, но любой пакет, так или иначе, должен иметь адрес отправителя и адрес получателя, и чтобы это изменить нужно изменить протокол передачи данных. Если я ошибаюсь, то дайте пруфлинк на практический пример.
Первое же по запросу в Google:
rfc2.ru/2827.rfc
Там рассказывается как с этим бороться
Ошибаетесь.

В курсе, что, к примеру, поля в email (как то from) элементарно подделывается? Тут тот же механизм, ни чего не мешает передающей стороне указать не свой реальный IP адрес, а вообще какой угодно. При такой атаке просто трехэтапное рукопожатие не завершается, но злоумышленнику это и не нужно. В частности это используется в таких атаках как IP spoofing.

Бороться с такого рода атаками можно только на уровне провайдера оборудование которого смотрит IP адрес отправителя и убеждается, что он соответствует адресу указанному в заголовке пакета. Но зачастую это не делается, потому что указание не «своего» IP адреса вполне себе легитимный механизм и есть системы использующие это.
Если я правильно понимаю, речь идет об IP-spoofing — атака, заключающаяся в использовании в IP-пакетах, отправляемых жертве, в качестве обратного адреса IP-адрес хоста, которому она доверяет; легко осуществима в UDP, в некоторых случаях возможна в TCP-соединениях.

Знаю такую гадость, но насколько мне известно сейчас подобное блокируется выше на уровне ДЦ, хотя могу ошибаться.
На уровне сервера это решается настройками sysctl, правда в случае с забиванием канала это конечно не спасет.

Было бы интересно если бы кто-то, кто имеет отношение к провайдерству прокомментировал, актуален ли сейчас IP-spoofing.
Конечно, актуален. Не далее недели назад видели spoofed-атаку в 1,5 Гбит/с, и вообще регулярно их видим. Даже речи не идёт о том, чтобы сбрасывать их со счетов.
Не встречал еще пока такого ДЦ, который бы детектил IP-spoofing. Во-первых, это не делается по той же причине по которой невозможно на роутерах ДЦ рулить блокировкой. Фильтровать трафик на это уровне долго и дорого (относительно варианта «не фильтровать» конечно же). И вторая причина, хоть в IP-spoofing и используется подмена адреса в зловредных целях, есть ряд вполне себе нормальных систем которые используют такую схемы работы (т.е. указывают не «свой» IP адрес, а чужой, но на этом «чужом» адресе входящий пакет принимается штатном режиме).
Что то я не понимаю, каким образом это можно осуществить?
Ведь если подставлять совсем уж рандомные адреса, то они просто напросто не будут смаршрутизированы оборудованием дата-центра, откуда идет атака. Есть конечно вариант занимать соседние адреса из своей подсети, не используемые в ДЦ, но в этом случае можно схлопотать по шапке от ДЦ еще до прихода абузы.

Да и большинстро «поROOTенных» серверов не является таковыми. В большинстве случаев — это дырявые скрипты на сайте, соответственно для проворачивания таких вещей привилегий маловато.
От случайных ИП защитит uRPF-failed на самом сервере, мощные атаки бывают как правило по UDP, (10 — 20гигабит), в таких случаях следует обращатся к своему хостеру с просьбой зарезать весь UDP к серверу, и проблема будет решена.
В случае атаки 20 гигабит максимум что можно сделать, не обладая существенными денежными ресурсами, это поставить свечку и заказать панихиду по серверу, а самому податься в философские размышления на тему «кто же меня так не любит и кому я так насолил».
Мы в свое время пытались тыкаться по ДЦ которые бы нам смогли порезать трафик, это я вам скажу совсем не тривиальная задача (найти такой ДЦ)
Опять же зависит от хостера, если хостер надёжный, то с ним и в огонь и в воду, в обиду не даст. :)
Вот буквально 04.12 поливали клиентов как из ведра (СМИ), ничего устояли, живы целы, саппорт в усиленном режиме работал.
Ну если еще будет актуально — всегда велкам,
мы всегда помогаем клиентам.
неудачный ход мыслей
Во-первых, все стороны в конечном итоге теряют деньги (владельцы бот-сетей не в счет)
Во-вторых, Билайн блокирует зараженные машины клиентов без предупреждения (год назад столкнулся с таким случаем). И требовалось очень долго висеть на линии техподержки, выясняя причину блокировки и последующего подключения
Владелец зараженной машины так или иначе должен нести ответственность за свою машину, в противном случае от подобной безответственности деньги как раз начинают терять ни в чем не повинные владельцы атакуемого ресурса. Да и сам владелец машины может в таком случае долго оставаться в неведении об «альтер-эго» его компьютера.
А блокировка без предупреждения это скорее изъян самого билайна, а не хода мыслей в целом. Так или иначе, abuse-адреса именно для этого и существуют.
Да и билайн, думаю, тоже понять можно. Слишком много ресурсов уходит на анализ каждого подобного случая, связь с владельцем машина, а таких случаев в день может быть иысячи.
А зачем атакующему знать, что работает «сильный админ»? Пусть лучше не знает.
Другое дело, что воспитатель в садике может крепко по попе надавать, и отбить желание впредь пакостить. Ничего «детского» в этом нет.
(Ведь если вас, не дай боже, побьют или ограбят — вы вооружаетесь и идёте мстить, вместо того, чтоб обратится в милицию? Не думаю.)
Ну немного не в тему, но про сильного админа логика не лишена смысла. Тут имеет место чисто психологический момент. Если ддосеры (или заказчики ддоса) видят, что админ показал зубки и начал обороняться, к примеру ресурс начал пусть через раз, но открываться, на главной нет плаксивых историй о мегаддосе, зато видно что администрация онлайн, работает, сообщает о том, что все действия ддосеров логируются для последующего анализа, абузы рассылаются…, это может повлиять на решение о прекращении ддоса.
Идеальная жертва ддосера — ресурс, который тут же складывается намертво и не предпринимает ни каких действий к обороне, на главной куча слез, мол «мы ничего не можем сделать, ддос мощный», никаких попыток логировани и анализа трафика не предпринимается, абузы не шлются.
Решение о прекращении принимается тогда, когда заканчивается оплаченный срок. До этого момента никто ничего не будет прекращать по собственному желанию. Исполнители не будут прекращать потому, что услуга уже оплачена, а заказчикам вообще нет смысла отменять (выгоднее сменить исполнителя).
Ботнет пополняется ежечасно (если не чаще), а ваши абузы, в лучшем случае, начнут работать через день. Владельцы ботнета от этого не пострадают.
По поводу срока согласен, но думаю врядли заказывают ддос на месяц сразу. Обычно берут на пробу час или несколько часов.
В случаях с ДЦ абузы работают достаточно быстро, хотя понятно, что тут не идет речь о том что это панацея и все должно моментом сработать. Пусть до кого-то дойдет уведомление даже через месяц и на одного бота в мире станет меньше. В совокупности это может дать эффект.

Тут важно не просто писать абузы, а подкреплять их логами. Даже по логам иптрафа можно увидеть что трафик совершенно ненормальный (несколько десятков тысяч соединений в сек с одного ип адреса, явно нормальными ни как не назвать).
Кстати повторюсь, бывают случаи, когда блокировка не дает ни какого эффекта и при полном DROP всех соединений сервер лежит, из-за того что, например, канал забит или сетевая не справляется с запросами.
Сейчас ввиду распространения широких каналов данный вид аттаки набирает популярностью. Тут уже не обязательно десятков тысяч ботов. Достаточно всего лишь купить несколько протрояненных дедиков на широких каналах чтобы с них терроризировать любой ресурс.
По собственному опыту скажу, что просить вам ДЦ помочь порой бесполезно, ибо им проще скинуть такого клиента, чем перестраивать свои конфиги. А если вы работаете через реселлера, то тут задача усложняется до почти невыполнимой.
Причем тут скинуть? В нормальных ДЦ есть услуга «Защита от DDOS». В некоторых даже временная (включается на время атаки). Но это конечно стоит денег.
Ну в нормальных это слишком обобщенно сказано, таких ДЦ можно на пальцах сосчитать, которые действильно могут защитить, большинство будет защищать на 3 — 4 уровне оси, на л7 практически никто небудет защищать, но у многих есть API для того что-бы управлять услугой, и тогда — логика на самом сервере (самое правильное место) а по API информация передается на ферму блокировки в ДЦ.
Злостный ДЦ у вас наверное, раз непомогает своим клиентам,
от себя скажу как хостер — помогать клиенту в таких случаях крайне необходимо,
ибо атака в несколько гигабит, может не только сервер клиента положить, но и всю стойку с другими клиентами.Хотя и встречались такие ДЦ, которые при ДДоСе просят клиента уйти по-дальше, для таких — всегда велкам :)
а мне наоборот кажется, что решение очень красивое. продолжая ваш пример с детским садом: Вася ударил Петю, Петя надел шлем, Вася взял молоток, Петя решил просто спасаться бегством при виде Васи, тогда Вася надел ролики, Петя одел платье Маши в надежде, что его не заметят и так далее… Именно с этим можно сравнить обычные решения проблемы ДДОСа, разве это красиво?
А если просто через воспитательницу объяснить Васе, что так делать не хорошо, то это будет проще, эффективнее и красивее:)
У Вас «детское» сравнение, попробуйте сделать его постарше, предположите вред чуть больший, чем просто «толкнул». Вы считаете, что сообщить «куда надо» будет хуже, чем сделать более грозный вид, чтоб не приставали, и пусть «обижают» других?
В топике ведь речь не про «пожаловаться», а скорее про «воспользоваться» основным доступным вариантом ответного воздействия.
UFO just landed and posted this here
Хм, пожалуй да. Но отправка abuse писем тоже может быть замечена.

Вообще лучше всего наверно применять оба пути — и защита блокировками, и контратака abuse письмами.
Так что vkupriyanov здесь несколько не прав, считая практику отсылки abuse писем «детской» и несерьёзной. С технической стороны — может и так, не шибко умно (хотя смотря как реализовать ). Но с юридической и практической — вполне логичный ход.
Я ведь не предлагал свой способ, как единственно верный, в самом начале я говорил о том, что это не метод борьбы (хотя в некоторых случаях он может и являться таковым).
Это просто логическое дополнение к основным методам защиты.
Можно конечно сидеть в крепости с высока наблюдая за осадой, а можно бомбить в ответку, по одному отстреливая нападающих.
Наши админы настолько суровы, что они ддосят ботнеты.)))
Пара тезисов:
— UDP/ICMP/SYN-флуд, как правило, ведётся со spoofed (затрудняюсь сказать по-русски) IP-адресов, и жаловаться на них можно хоть в спортлото;
— атаки уровня приложения, как правило, ведутся с нескольких тысяч IP-адресов заражённых десктопов, и жаловаться на них можно их провайдерам до бесконечности. Малая часть провайдеров захочет принимать какие-то меры, и, к большому сожалению, ещё меньшая обладает техническими специалистами уровня, достаточного для реального решения проблемы. В результате из 10000 ботов вы отсечёте, ну, сотни четыре, при этом потратив существенное время на переговоры с сотрудниками каждого из провайдеров, иногда ещё и не на русском языке. Толку от таких действий — никакого.

Having said that, изредка случаются атаки с дедиков без спуфа, и abuse@ может помочь в этом случае. Проблема в том, что время реакции abuse@ составляет иногда до 4 дней. Так что жалоба — это именно не решение проблемы, а месть атакующим.

Нужно также понимать, что если атакующие не скрывают IP-адреса источников атаки, то будущее этих источников им до лампочки — машины заражены/взломаны, имя им — легион, и управляются они из командного центра. Так что и мстите-то вы скорее для собственного удовольствия.
UFO just landed and posted this here
Само собой. Однако в то же время эти толпы являются целевой аудиторией абсолютного большинства рентабельных сервисов Рунета, и, если эти толпы поставить к стенке, данные сервисы просто перестанут существовать.

Моё личное узколобое предвзятое мнение состоит в том, что провайдеры должны как-то, ну, ухаживать за своими клиентами. Антивирусы там дарить или бесплатное регулярное техобслуживание. А то развешивать рекламу и дарить домохозяйкам бесплатное подключение все горазды, а потом на этих домохозяек их провайдер плюёт с высокой колокольни.
Провайдеру это не выгодно. Какая бесплатная поддержка, когда зачастую даже для штатных работ нанимают студентов которые в предметной области очень сильно плавают. И это даже не беря в расчет соображение о том, юзера любят временно отключать антивирусник когда им кажется что он мешает работе системы.

Имхо, решение есть, но оно должно проводиться на уровне государства и законов. И к этому еще придут. Просто это элементы безопасности и страхования рисков, как и ремень безопасности в машине или ОСАГО. Вводить ответственность для конечно пользователей глупо, имхо, как нетехнические специалисты это не их дело. Но административную ответственность вводить для лиц устанавливающих антивирусные системы. Приглашать или нет такого спеца дело должно быть добровольное, но если нет актов от установленном и настроем ПО от таких специалистов, то ответственность на владельце компа. В нормально законе рецидив должен учитываться. Т.е. в случае первого нарушения ни какие санкции кроме уведомления не применяются. После этого адекватный пользователь либо произведет нормальную настройку, либо пригласит спецов и получит бумагу под это дело. Ну а не внял, значит применять прогрессирующую шкалу штрафов.

В общем как и в программинге реализуемо все, вопрос воли и желания.
Не забудьте, что задача выяснения того, что данная конкретно программа — вредоносная — алгоритмически неразрешима…
Проблема в том, что антивирусные системы тоже обладают неплохой такой инерцией. То есть искоренить вирусы и ботнеты не удастся, они будут всегда, вопрос только во времени их существования и в скорости реакции ответственных за их обезвреживание лиц.

При этом организовать быструю реакцию техподдержки провайдера вполне реально. Оная техподдержка, по-хорошему, так или иначе должна быть круглосуточной и иметь в штате толкового технического специалиста, и она может оперативно заблокировать трафик по определённому признаку (например, IP-адрес назначения) по экстренному запросу. А вот организовать быструю реакцию эникейщиков-спецов по установке/обновлению антивируса невозможно.

Но, конечно, это можно воплотить в жизнь только на уровне законов. Призывов к сознательности здесь явно недостаточно.
UDP/ICMP — блокируются спокойно у хостера, даже на простой циске (свиче) простейшим аксес-листом.
SYN — это уже можно передавать хостеру у которого есть услуга защиты от ДДоС,
всёж лучше чем нагружать интераптами простой сервачок, хоть и дороже.
Вот хомячки — это больная тема, «домашние» провайдеры как правило медленно реагируют на абузу, тут спасает либо капасити сервера, либо услуга от ДЦ.
Насчёт времени реакции, ДЦ заинтересованы отвечать быстро, 24 — 48 часов макс.
т.к повторюсь (ниже уже писал) ниодин ДЦ, не хочет славы абузоустойчивого ДЦ со всеми вытекающими.
24-48 часов это быстрое время реакции? В нашем случае, например через 48 часов можно было бы уже закрываться и попрощаться со всем проектом.
Посему наедятся тут на ДЦ достаточно рискованно. Тут надо оценку делать, или справляться своими силами, или фильтровать трафик на стороне.
Это конечно хорошо когда ДЦ помогает, но мне таких на жизненном пути не встречалось, может просто не везло. Им намного проще потерять одного клиента, нежели поставить под удар все оборудование и потерять всех остальных.
В данном случае, приведены макс. позволительные для хостера сроки, у многих ДЦ поддержка 24х7, и обычно реакция незамедлительна (хотя опять же, судим по себе, и по партнёрам).
Может быть и проще потерять клиента, но раз клиент, два клиент, три клиент,
а потом и репутацию надёжного партнёра, с которым можно вести дела, и потерять можно.
SYN — это уже можно передавать хостеру у которого есть услуга защиты от ДДоС

а может просто включить SYN cookies?
Вы правы, SYN cookies / SYN proxy поможет боротся с SYN флудом, но с маленьким,
если вы не упрётесь в процессор (я имею ввиду прерывания, на обработку которых весь ресурс процессора будет выделен) то вы упрётесь в ширину канала сетевой карты (при больших атаках).
Так что боротся можно и самому, но со «школьниками» без помощи ДЦ (редкие ДЦ) / внешнего сервиса (дорогие сервисы) тут уж точно не обойтись.
а ещё довольно таки часто обращения на abuse@ или валятся в какой-нибудь редко проверяемый ящик, или адрес вовсе не работает (для Азии и Южной Америки вполне себе обыденность)
> — UDP/ICMP/SYN-флуд, как правило, ведётся со spoofed (затрудняюсь сказать по-русски) IP-адресов, и жаловаться на них можно хоть в спортлото;

Задавал уже в комментариях этот вопрос, все же. Разве spoofed-травик не отвалится сам собой на маршрутизаторах ДЦ, в котором расположен атакующий хост?
Не отвалится. Во-первых, не все ДЦ заботятся о такой фильтрации. Во-вторых, существуют IX, где вообще мало кого интересует, что там происходит на подключенных машинах. abuse@ у ряда IX абсолютно непробиваемый.
Странный итог статьи, разослали письма, и не сказали уменьшилась ли атака. Только рассуждения что возможно найдутся люди которые отреагируют.
Но мне больше видится сценарий что через пару месяцев таких автоматических абуз ваш ip попадет в спамхаус и аналоги. Ip spoof здравствует и процветает.
Если говорить про мой конкретный случай, да это помогло. В основном долбили пара десятков дедиков на мощных каналах, после абуз они исчезали, от ДЦ почти всегда приходили ответы.
Маскировать ip ддосеры не пытались.
По письмам, отосланным на адреса простых ботов, ответы приходили еще на протяжении пары недель. Где-то стандартные шаблонные отписки мол ваш запрос принят, разберемся, где-то писали мол уведомили клиента или заблочили.
Спасибо за статью, хотелось бы узнать насколько с практической точки зрения данный метод эффективен?
В принципе от зараженных дедиков — очень даже, многие ДЦ реагируют быстро,
это в их же интересах, никому ненужна слава абузоустойчивого хостера.
ваше решение по моему опыту будет неработоспособным. Всё хорошо, кроме поиска электронных адресов и отправки писем.
whois IP|grep mail
это как-то отстойненько. Когда-то я тоже решал похожую задачу и так не нашёл способа универсально парсить ответ whois — он очень сильно различается для разных зон.
Вторая проблема — после некоторого количества запросов за единицу времени whois просто перестаёт отвечать вообще. Я так понял, это защита от ДДоСа или как-то так.
>>> ваше решение по моему опыту будет неработоспособным. Всё хорошо, кроме поиска электронных адресов и отправки писем.
А вы попробуйте. :) Перед тем как выложить скрипты я их проверял на работоспособность. Если знаете что можно улучшить, код на гитхабе, там это все можно осуществить.

>>> whois IP|grep mail это как-то отстойненько.
Все гениальное порой очень просто, почему оно должно быть сложным?

>> Вторая проблема — после некоторого количества запросов за единицу времени
возможно, но я на такой лимит не натыкался. Думаю если чекать 100 тыс ботов, это будет проблемным, но в отличие от общепринятого мнения ботов не сотни тыщ, а вполне определенное количество, поэтому в большинстве случаев проблем не должно возникнуть. Можно разбить проверку на группы и делать задержку. Я просто не хотел усложнять скрипты, в них принцип работы, который каждый волен настроить под себя.

>>> Я так понял, это защита от ДДоСа или как-то так.
своершенно не правильно поняли, данное решение совершенно не претендует на способ защиты и я об этом писал. Это одна из возможных составляющих оборонного комплекса, эдакая месть, если так проще для понимания. Возможно вам оно ни как и не поможет, но поможет кому-то еще.
Забавно, сам не так давно озаботился подобным (на базе логов Apache).
Конструкцию whois IP | grep mail не использую, т.к.:

а) это приводит к отправке бесполезных абуз на адреса ripe.net, ripe.net и т.п.;
b) пропускаются некоторые адреса из whois (например, для 77.239.176.4 будет пропущен адрес abuse@vegatele.com)

+ время от времени адреса в полученном списке будут дублироваться, а "… | uniq", используемый в mail_send.sh, без предварительного "… sort | " мало помогает делу:

$ whois 101.51.103.66 | grep mail | awk '{print tolower($0)}' | egrep -o "\w+([._-]\w)*@\w+([._-]\w)*\.\w{2,4}" | uniq
arin@apnic.net
apipolg@tot.co
abuse@totisp.net
apipolg@tot.co
abuse@totisp.net
ap@gmail.com

$ whois 101.51.103.66 | grep mail | awk '{print tolower($0)}' | egrep -o "\w+([._-]\w)*@\w+([._-]\w)*\.\w{2,4}" | sort | uniq
abuse@totisp.net
ap@gmail.com
apipolg@tot.co
arin@apnic.net

Поэтому использую громоздкое, самописное, кривое и избыточное, но зато рабочее:

$ whois 101.51.103.66 | sed -e 's/^.*ripe.net//' -e 's/^.*@apnic.net//' -e 's/^.*@lacnic.net//' |
grep -E -o "[a-zA-Z0-9_.-\S]+@[a-zA-Z0-9_.-\S]+.[a-zA-Z0-9_.-\S]+.[a-zA-Z\S]{2,6}" | sort | uniq
+ Забыл в предыдущем комменте сказать — Ваш регексп не берёт адреса типа ***tot.co.th
На примере того же 101.51.110.248 сравните вывод:

whois 101.51.103.66 | grep mail | awk '{print tolower($0)}' | egrep -o "\w+([._-]\w)*@\w+([._-]\w)*\.\w{2,4}" | sort | uniq
whois 101.51.103.66 | grep -E -o "[a-zA-Z0-9_.-\S]+@[a-zA-Z0-9_.-\S]+.[a-zA-Z0-9_.-\S]+.[a-zA-Z\S]{2,6}" | sort | uniq

И адреса в доменах типа .travel тоже мимо кассы пойдут
Sign up to leave a comment.

Articles