Как стать автором
Обновить

«Поздравляем с терабитом». Та самая статья про DDoS-2023 — без цензуры

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров31K
Всего голосов 86: ↑84 и ↓2+102
Комментарии46

Комментарии 46

Тема осталась нераскрыта:

Что требуют ddoser'ы?

Это же была не просто демонстрация могучести пубертата, которому девки не дают, зато он вон какой нагибатор, тут же что-то личное?

Плюсую, нужно раскрыть тему сеерверов по 188, у самого сервера в tw, одно и дело читал чат ddos alerts, и проверял отвалился или нет

Можно начать с того, чтоб посмотреть на тех кому это выгодно. Т.е. конкуренты.

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

Как я Вас нашел? - это реклама и постоянные статьи на хабре) Баннеры крутые)

Что в целом нравится - ЛИЧНЫЙ КАБИНЕТ и управление вдс своим интерфейсом) это футуристически) кайф

ДДОС 2023 почти уничтожил мой проект, мне пришлось делать зеркала на DigitalOcean и платить за каждый гигабайт. Если у вас в чате орали, то у меня кричали в чате где было 11к людей.

Так что ДДОСЕРЫ требовали? кому нужно столько мощности вливать на уничтожение вашего проекта?

Да, у меня был чудесный сервер в Нидерландах с хорошим IP, но та длительая атака привела к тому, что пришлось временно перейти к другому провайдеру на букву А, а там по акции поймал тариф с отличной ценой и так там и остался. А кабинет в TW и их постоянные новые фишки (в т.ч. по просьбам пользователей) очень нравились

Вряд ли вы будете в реальной безопасности пока вы или будете использовать CDN (фильрация DDoS фактически бесплатная, есть под опции) или пользуетесь большими облаками.

Ясно, что вероятность атаки на мелких хостингах обычно мала, но им легко тупо забить канал и от вам могут просто отказаться (есть примеры статей на Хабре). Даже в этой статье указано на увеличение каналов, но им просто нужна будет более силная атака чтобы забить каналы. (хотя площадки в москве и европе делают их сеть более распределенной, но они никогда не сравняться с 150 PoP-ами CDN)

спасибо за статью, действительно интересная)

Молодцы, ребят. Я в Вас верил) Скоро планирую вернуться, ибо вынужден был переехать)

Статья прикольная, только вы постепенно превращаетесь в Мастерхост. По уровню сервиса, чувству клиента и постоянному повышению цен, и скрытым/навязанным услугам в ЛК (за что в "Идеи" вам уже напихали как следует). Плюс, неконкурентные цены на cloud в принципе. Сюда же можно отнести дикий ценовой перекос между ЦОД, взять даже СПб и Москву (я уже молчу про KZ). Ну это так, у слову. Теперь про ваш ДДОС и "ваш кампф" с ним со стороны клиента.

Сайты падали в течение недель, и ни извинений, ни зачислений на баланс за даунтайм и дичайшие тормоза, не последовало. Как не последовало и выступления ваших топов, почему же они такое допустили. И вот спустя квартал, мы получаем как бы интересную статейку для технарей "посмотрите какие мы молодцы" + немножко смеха про пиво и прочее, чтобы отвести от основной темы и негативного повода в целом. Таким образом, бизнес переложил ответственность на технаря, продолжая дальше отсиживаться в темном углу. Самое простое и самое недальновидное решение.

С точки зрения техники (сети на скоростях в ~терабит) оценить ваши действия профессионально не могу, но как у нас принято, действовать вы начали, когда было уже поздно, и когда я уже в ТП написал, что ухожу нахер с 25 проектами. Так что хвалиться тут есть не особо чем - примерно, как "у нас загорелся дом, мы посмотрели, как он горит, а потом начали покупать огнетушители и перемещать их к месту пожара". И это опять вопрос качества менеджмента, именно бизнесового, а не технического.

TW, у вас там точно всё в порядке в плане управления? Выглядит со стороны так, как будто на волне успеха наняли "эффективного менеджера" из Кока-Колы. Или отец передал бизнес сыну, который обычно проводил время в клубе Soho.

Однозначно плюсую. Свалил от них в этот момент на DO. Причем базы перелить в момент атак тот еще квест. DigitalOcean дорого, но там меня ценят, вернее ценят мои деньги и дают мне максимум качества по этой цене. А TW судя по поведению, еще много хлопот может доставить.

Кстати, компенсацию за даунтайм они начислили, мне на баланс зачислилось целых 54 руб, без ноликов.

Вы просто везунчик! Теперь то на эти деньги сможете купить себе 1 поездку на метро в Москве.

Ага. Я так радовался, что почти обоссался от счастья

Судя по сумме - у вас был минимальный тариф за 188? Или это вы назвали только одну из нескольких компенсаций?

У меня было несколько серверов и две базы. Это столько суммарно мне начислили.

Забавно. У меня в том регионе был только минимальный сервер и начислили 49+15 за простой сервера.

Видно какой то рандом в начислениях. Я сейчас уже спокойно вспоминаю то время, но забавно было то, что у меня одно приложение ревью проходило в apple. Я молился, чтобы атаки не было в моменте, когда ревьюер затевые запросы проверять будет к серверу. В итоге, перелился более-менее без потерь. Очень помогло, что у меня платный ДНС на Zilore и я смог быстро переключить адреса на все точки входа АПИ. Но TW теперь для меня триггер на нестабильную работу без уведомлений!

Я по обращению ~300 получил

Как мне доходчиво объяснили в примере со сбером, что Вы должны радоваться, что Вам контора проявила так сказать свою милость и что-то компенсировало. Должны радоваться и не пытаться переводить свои хотелки в разборки "по понятиям" :)

Так мы и радуемся =) Радость не омрачает даже то, что они мне сервис с десятками тысяч пользователей чуть не похоронили, так как не удосужились прислать уведомление!

Компенсация в зависимости от потребления затронутого сервиса, больше потребления - больше компенсация, в рамках SLA

И это опять вопрос качества менеджмента, именно бизнесового, а не технического.

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

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

А может просто и тех, и других? ?

Я отталкиваюсь от того, что написано в тексте, а не от того, что и где еще бывает.

А если CIO/CTO что-то не заметили, то на совете директоров это должно вскрыться весьма быстро

Каким образом? Вот сами представьте себе ситуацию - всё (до поры) работает, деньги выделяются, техдир исправно рапортует, что все идет по плану. Как бизнес догадается, что что-то не так?

Плюс, неконкурентные цены на cloud в принципе. Сюда же можно отнести дикий ценовой перекос между ЦОД, взять даже СПб и Москву (я уже молчу про KZ). Ну это так, у слову.

А какие тогда альтернативы? Просто я сколько не пробовал все + - одинаковые в РФ, ценами только разные.

Ребята. Я когда упражнялся у вас с базой данных Postgree. Услышал от саппорта фразу (не дословно): иногда данные теряются, надо с этим жить. То есть данная фраза вообще ставит под сомнение какое либо ответственное отношение к облачным базам данных. Я понимаю, что надо их резервировать. Но вот после таких фраз службы поддержки - вера в ваши бэкапы - НУЛЕВАЯ. При этом я параллельно общаюсь с Selectel.ru - и там ну совершенно другое отношение к таким вопросам. Вообщем это уровень ценностей. Подумайте над этим. В результате у меня сложилась такая картинка:

  1. Selectel.ru - для продакшена.

  2. timeweb.cloud - для наколенных экспериментов.

Так что ребята, вы молодцы - у вас дешевые цены для старта и хорошие виртуалки. НО для серьезного бизнеса, я бы пока побоялся к вам идти. Только как стенд для тестов.

Услышал от саппорта фразу (не дословно): иногда данные теряются, надо с этим жить.

Это у всех так. Амазон - в один прекрасный момент они дропнули все базы и "восстановили" их из бэкапа полугодовой давности. Куда делись все более свежие бэкапы они не знали.

Как много всего и сразу, давайте к сути) Есть SLA, по нему был перерасчет, вообще всем. Если вам нет, пишите, проверим. Извинений на коленях действительно не было - было перестроение сетей, огромное количество компромиссных решений и экстренный поиск дефицитного железа. Про все это прозрачно рассказали выше и рассказывали в наших оф каналах. И топы и не топы. И про то, что кто-то отсиживается или про некорректные управленческие решения - скорее всего вы нас с кем-то перепутали.

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

По ценам - скидывайте примеры облаков, где дешевле, посмотрим. По навязыванию - давайте с конкретикой, рассмотрим. По уровню сервиса - давайте тоже плиз с конкретными примерами.

Согласен с KPEM - во время атак не было никаких уведомлений, сообщений, в техподдержке толком ничего не говорили. Спустя несколько дней даунтайма в личном кабинете появилась надпись о том, то идет атака. Компенсаций хотя бы по абонентской плате не было, не говоря уже о потерянных деньгах своих проектов.

создал тикет, сделали компенсацию но не деньгами а просто списание выключили на несколько недель

Плашку об аварийных работах повесили в ПУ сразу. Потом, как только появилась полная информация о проблеме, то сразу сообщили

По запросу скорости мы даем вплоть до 100—200 гигабит на сервер, так мало кто умеет

О, спасибо, так организовывать DDoS гораздо удобнее!

Интересно, появятся ли на рынке услуги по поиску реальных исполнителей таких атак?

А можно ли улучшить ситуацию с борьбой против DDoS если фильтровать подозрительный трафик у отправителей? Например по такому принципу: если отправляются пакеты на некий адрес, а ответы с него не приходят, это похоже на попытки обратиться к адресу, находящемуся под атакой DDoS, и, если соединение на тот адрес в обозримом прошлом не устанавливалось, и если он не отвечает на пинги (или отвечает с большой задержкой), то это похоже на участие в атаке, и тогда соединение надо блокировать и уведомлять пользователя (может начиная с некоторого количества таких ситуаций).

Если бы такая возможность была в пользовательских роутерах и т.д. (понятно, что с возможностью отключения), то есть, если бы пользовательские устройства определяли возможное участие в DDoS-атаке даже при небольшом исходящем трафике, это наверное позволило бы сильно ограничить возможности атакующих.

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

По UDP оно и не обязано приходить. Бывают тем более еще и хитрые ассиметричные конфигурации.

Конечно более менее вменяемые провайдеры - не дают лить трафик с левых блоков адресов вот только проверка что они не левые если есть линк по BGP может быть затрудненной. Есть конечно rPKI...

Ну и - если DDoS вообще с 100500 завирусованных домашних машин.IP-понятны а делать что? Провайдера попросить блочить клиентов пока все для провайдера не совсем еще плохо? Так ему положат техподдержку такие домашние клиенты.

Ставить это в клиентски роутеры с их дохлыми процессорами? А оно клиенту надо эти тормоза из-за логики фильтрации?(если же роутер с нормальным процессором - клиенту наверно и так есть чем это загрузить, раз он такое купил). Кстати а как будем правила фильтрации обновлять?

Коллеги, привет!

Очень интересная статья, спасибо!

Вопрос "почему мы на спрятались за подрядчиками" обозначен, но четкого ответа на него нет. А это кажется самым очевидным решением в подобной ситуации. Это технически было невозможно? Или финансовые/административные ограничения? Или подрядчики отказались?

Буду благодарен, если распишите этот момент поподробнее.

В двух словах и не ответишь, заранее извиняюсь за полотно текста.

Динамически прям отворачивать не всегда выход из-за причин описанных в статье, что же касается подхода "анонсим все всегда через центры очистки", существует несколько факторов.


Обучение защиты

Основная(хоть и не единственная) часть бизнеса это всяческие vds и сервисы крутящиеся вокруг них - сервисы, которые приносят к нам клиенты. Это выливается в то, что в отдельно взятой /24 сети существует по меньшей мере 253 сервиса, о которых мы и уж тем более подрядчик ничего не знает, их состав постоянно меняется - клиенты приходят и уходят, меняют инфраструктуру и так далее. Умножьте эту проблему на 500 для понимания масштаба.

Обычно, когда практикуется такой подход, сети заводятся за клиринг изначально, с момента их рождения - защиты успевает подстроиться под клиентов, клиенты под защиту. Однако это был не наш случай.

Гео, RTT и связность

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

Заруливание входящего трафика через очистку также накладывает ограничения на связность: ладно PNI, через них редко что-то прям летит, но есть например точки обмена трафиком, и региональные операторы - придется или отказаться от коротких маршрутов для клиентов, или жить с тем что защита местами "протекает".

Экономика

Помимо всего прочего, с точки зрения Opex, сетевая инфраструктура для облаков не всегда имеет такую уж большую маржу как хотелось бы. Пропуск трафика через центр очистки, в среднем по больнице, стоит по меньшей мере в 10 раз дороже чем на сравнимой емкости транзит - не говоря уж о IX-ах. Это выливается в то, что в некоторых локациях входящий трафик средней виртуалки оказывался дороже чем собственно виртуалка - это если конечно не переподписывать площадку до дропов в ЧНН. Последним мы не занимаемся, а кратно выкручивать цены уже рынок не дает.

На наших масштабах получается что иметь широкую сеть и чистить внутри контура имеет больше смысла. Как дополнительный бонус - мы и клиентам по такому сценарию можем больше дать, как абстрактного интернета, так и каналов/маршрутов/доп сервисов.

Итого

Серебряной пули в этой ситуации увы не нашлось.
Профессиональные центры очистки трафика это важный инструмент, который мы продолжаем и планируем продолжать использовать. Мы плотно сотрудничаем с несколькими партнерами, там где нужен более продвинутый сервис для клиентов(L7) или направлений, которые не можем поддержать сами.

Но как общее решение для инфраструктуры уже не получается - и трафика многовато и развитие слишком динамичное, по совокупности факторов оказалось лучше самим строится.

Хорошая реклама, жалко в жизни все гораздо печальнее.

Мне нужен DBaaS в СПБ, создал в SPB-4 сеть и бд. Оказалось нельзя подключить сервер из локации SPB-1 в приватную суть в SPB-4. Ладно, хочу создать сеть и базу в SPB-1, но вот сюрприз, нельзя.

И зачем такая приватная сеть, если ее не в каждой локации можно создать и с другими локациями она не соприкасается? Ладно между серверами я могу поднять VPN, а к DBaaS как обращаться?

Как то держал там свой сервер по майнкрафту и в итоге пошли ддосы, проект чуть ли не распался.
В итоге ушел к облачному-хостингу AEZA и забыл что такое вообще атаки.

Якобы сейчас вы сделали себе крутую защиту, но тогда почему я не могу адекватно ставить свои сайты на вашем хосте?
Почему любой дурак может взять и с хорошим ддосом его положить?

Также почему я не получил компенсации при прошлых атаках?
ТП меня игнорировала или убегала от ответа.

Причин того, что вы не можете адекватно ставить сайты на нашем хосте может быть огромное множество, включая проблемы, завязанные на особенности настройки ОС клиента. Напишите в поддержку, поможем, или скажите номер тикета.
Про ДДОС-атаки, которые могут сейчас положить весь наш сервис - приведите пример, пожалуйста, разберем.

Компенсация была выдана всем в зависимости от потребления затронутого сервиса, больше потребления - больше компенсация, в рамках SLA
нужно обратиться в поддержку, чтобы понять, что за ситуация сложилась

Когда вы уже прикрутите в ЛК хостинга возможность самостоятельно выключать Aaaa запись у доменного имени. Также было бы классно самостоятельно выключать A запись, оставляя только AAAA. Кроме сайта на Битриксе держу у вас с десяток доменных имен, и каждый раз все приходиться через техподдержку решать.

Особенно палевно, когда удаляешь ручками АААА а он назначается системой из каких-то «по умолчанию». Только тебе этого не видно в панели управления, и понять почему трафик не ходит можно только выполнив nslookup и внезапно обнаружив там ipv6 адрес, который тебе сосватала ваша система.

Плашку об аварийных работах повесили в ПУ сразу

В ПУ, доступа к которой не было?)

Извинений на коленях действительно не было

Я не помню вообще каких-либо извиненей) Возможно и были, но прошли мимо меня.

По уровню сервиса - давайте тоже плиз с конкретными примерами.

У FastVPS тех поддержка лучше) Ушёл от них скрепя сердцем, только из-за проблем с оплатой хостинга.

Статья интересная, если читать её в отрыве от компании)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий