В 14:30 2 мая сервисы провайдера Таттелеком перестали нормально работать.
По совместительству админю офис, который находится за городом. Парк около 70 ПК + несколько удалённых ПК через VPN. Начало месяца и у строителей период "предъявления выполнения", а без доступа к интернету его не предъявить.
Т.к. перебои с интернетом не в первый раз, в роутере стоит сим-карта как резервный канал.
Вроде, всё предусмотрено, но тут начинается веселье:
1. Роутер не переключается автоматически на резервный канал, т.к. на основном канале пинг проходит, но пользоваться интернетом всё равно невозможно.
2. Т.к. нахожусь дома, прошу отключить кабель основного канала от роутера. Отключили. Резервный канал всё равно не работает. Индикатор работы мобильной сети горит красным.
3. Рабочий день заканчивается, сотрудники уходят. Еду в офис, вынимаю сим-карту, а она как будто оплавилась - кривая. Короче, не работает. Еду обратно в город, получаю в офисе оператора новую, еду в офис, установил - работает. Подключил кабель основного канала - тоже работает.
4. Возвращаюсь домой - роутер недоступен. Звоню в Таттелеком - говорят, что проблема будет устранена к обеду 3 мая.
5. Утром прошу снова отключить кабель основного канала. Работает резервный канал. Часть сотрудников отправили домой, а там такая же засада - тот же провайдер Таттелеком. Бо́льшей части сотрудников в офисе отключаю доступ, чтобы остальные могли выполнить самую важную работу, т.к. резервного канала не хватает на всех для полноценной работы. К обеду постепенно подключаю всех с ограничением скорости в 1 Мб/сек. Сотрудники успевают сделать всё важное.
Наконец-то вечер пятницы. Можно выдохнуть.
Сейчас время 23:00, наверняка все проблемы устранены, переключаю удалённо на основной канал - роутер больше недоступен...
Вчера в 19 часов престали работать. Я до 24 часов прождал, позвонил провайдеру. Оператор сказала, что идет дос атака, специалисты работают.
Сегодня до 17 часов в сеть не заходил. В моменте, ЯП, Телеграм, поиск и почта Гугл не загружаются. Пикабу, Рамблер почта, ВК, поиск Яндекс работают. Не работает ВПН.
Инженер-программист Дэнни Го рассказ, что его кошка вовремя разбудила спящего хозяина, тем самым предупредив о DDoS.
Несколько лет назад Го работал в стартапе, в нем не было дежурства за работой сайта. Это было осознанное решение компании, тк быть на дежурстве сложно, а команда и так справлялась, следя за срочными сообщениями.
Только работает схема днем, а ночью никто за сайтом никто не следит, по причине сна.. (вспоминается советский анекдот про полет на солнце ночью)
Около трёх часов ночи я проснулся от того, что моя кошка вылизывала мне волосы. Само это действие не было чем-то необычным. Время от времени она делала это, и я оптимистично воспринимаю это как знак того, что я ей действительно нравлюсь, а не того, что она просто меня терпит. Но за 9 лет это был единственный раз, когда она сделала это, пока я спал. Я проверил свой смартфон, чтобы узнать, который час, и заметил, что пару минут назад сработало предупреждение AWS CloudWatch из-за неработоспособных сервисов нашего балансировщика нагрузки.
Я пытался зайти на наш сайт со смартфона, но он не загружался. Я начал проверять логи на рабочем ноутбуке. Наша панель мониторинга показала огромное количество запросов, поступающих со многих IP-адресов, связанных с разными странами. Да и международный трафик для нас не был типичен, поскольку наши сервисы были доступны только жителям США. Это была распределённая атака типа «отказ в обслуживании» (DDoS).
Моей первой и не самой удачной мыслью было заблокировать IP-адреса на уровне сервера, что было бы утомительно и, возможно, неэффективно, если бы у злоумышленника было значительно больше исходных IP-адресов. Но потом я вспомнил, что мы уже настроили брандмауэр веб-приложений AWS. Чтобы справиться с немедленным сбоем, я установил правило блокировки запросов из других стран. Оно вступило в силу и в течение следующего часа заблокировало сотни тысяч запросов. Наш сайт снова заработал, поток запросов прекратился.
Позже тем же утром в команде заметили, что получили электронное письмо в нашу службу поддержки примерно в то время, когда началась атака. Отправитель, используя ужасную грамматику, заявил, что нашёл уязвимость на нашем веб-сайте, приводившую к сбою Apache, которую мы не устранили. Злоумышленник угрожал, что заблокирует наш сайт и сможет сохранять его в таком состоянии в течение нескольких месяцев. Он великодушно предложил нам «файл с решением», если мы отправим ему $5000 в биткойнах. Мы не ответили, хотя, оглядываясь назад, можно сказать, что было бы забавно попытаться его троллить.
«Мне до сих пор трудно поверить, что моя кошка разбудила меня в идеальное время. Вы можете предположить, что предупреждение AWS заставило мой телефон вибрировать или издать звук, разбудив первым мою кошку. Но ночью я держу телефон в режиме «Не беспокоить». Так что мне просто нравится думать, что каким-то образом она почувствовала, что что-то не так, и это не могло подождать до утра. Это был, конечно, более приятный способ проснуться, чем рёв будильника», — подытожил Го.
Отсюда вывод, что кошки чувствуют электромагнитные волны, исходящие от телефона)
И когда у нас будет сайт заведем дежурную кошка, сэкономив на дежурстве.
30 тысяч белгородцев трое суток находятся без интернета из-за хакерской атаки
О проблемах с интернетом массово стали сообщать абоненты провайдера «Лучше.net». Жители частного сектора могут воспользоваться только этим оператором, поэтому вынуждены третий день подряд сидеть без интернета. Точные сроки восстановления провайдер сообщить не может.
Белгородцы, проживающие в частном секторе, жалуются, что у них третий день подряд нет интернета. Причина в том, что у единственного провайдера «Лучше.net», который проводит оптоволокно в частные дома, наблюдаются проблемы: автоответчик компании ООО «БТСК» «Лучше.net» сообщает белгородцам, что сеть подверглась DDoS-атаке — перегрузке сервера.
Когда жителям ИЖС стоит ждать возвращения интернета, в компании сказать не могут. По их словам, если бы точные сроки возвращения интернета были, то абонентам бы обязательно сообщили.
«Наши специалисты активно работают над устранением проблемы, однако точных сроков восстановления при таких инцидентах нет», — заверили белгородцев в компании. Дозвониться в техподдержку у жителей не выходит — вся сеть оператора перегружена.
Компенсировать абонентскую плату белгородцам тоже не спешат, потому что «причина возникновения неполадок не связана с качеством услуг». В то же время другой провайдер в подобной ситуации компенсировал абонентам плату за день.
Белгородцев такой расклад не устраивает: они возмущены, что во время неспокойной обстановки в регионе остались совсем без интернета. По этой же причине многие жители в настоящий момент работают удалённо, но из-за отсутствия интернета выйти на работу не могут.
Люди из-за этого не могут выйти на работу/учёбу, а у кого вообще всё и сразу. Вы уж будьте добры: или оказывайте услугу в полной мере, или сделайте перерасчёт.
попросили жители
Несмотря на то, что интернет всё-таки периодически появляется — на несколько минут раз в пару часов — большинство абонентов уже стали задавать вопросы, как расторгнуть с компанией договор.
По состоянию на 5 февраля к данному провайдеру подключено 30 тысяч абонентов — примерно столько белгородцев в настоящий момент находятся без интернета, однако цифра к 28 марта могла вырасти в разы.
Средство массовой информации зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций. регистрационный номер серия ЭЛ № ФС 77-74127 от 23 ноября 2018 г.
От себя добавлю, что я сам живу в пригороде и пользуюсь услугами этого провайдера. А другого у нас ПРОСТО НЕТ! ЛУЧШЕ.НЕТ, БЛИН!!!
И еще - может знающие пикабушники разъяснят по DDoS-атакам? А то я чего-то сомневаюсь... Нафиг кому-то нужен этот местный провайдер?
П.С. Пишу сейчас с мобильного инета, который у мня в деревне не просто медленный, а практически нулевой!
Этот материал должен был выйти в декабре 2023, прямо перед Новым годом, — и это классический пример про «лучшее враг хорошего». Сначала нам не нравилось, что мало подробностей. Потом — что их излишне много. Была версия с цитатами, но без скринов. Со скринами, но без цитат. Мы записали столько интервью с сетевиками, что сами в них запутались.
Но в итоге сегодня наша статья наконец-то выходит в свет. Из цензуры — только внимательная рука корректора. Передаем слово Максу Яковлеву.
Привет, Пикабу. Меня зовут Максим, я руковожу отделом сетевых инженеров в Таймвебе. Как вы уже поняли из заголовка, речь пойдет про наш прошлогодний DDoS. Это не стандартный постмортем, а скорее история от первого лица. Расскажу и покажу, каково это было изнутри — жить на энергетиках и пересобрать ядро сети всего за пару месяцев.
❯ Некоторое время до
Про Таймвеб вы, скорее всего, знаете. И скорее всего — как про хостинг, работающий по модели shared, с саб-сервисами вроде регистрации доменов, конструктора сайтов и пр. Еще есть облако, выросшее из хостинга, — о нем и пойдет речь.
В 2023 мы начали потихонечку распиливать легаси-сеть хостинга и делать ее похожей на сеть IaaS-провайдера. Но в целом архитектура на момент дня Х была довольно типичной для хостинга: несколько маршрутизаторов, стопка растянутых VLAN, три транзита и пара обменников.
В хостинговом бизнесе объем каналов рассчитывается от объема общего трафика на сеть, плюс запас на случай аварий и атак, обычно не превышающий 10х от трафика в ЧНН. Отсюда выстраивается защита инфраструктуры и клиентов: оценивается максимально ожидаемая совокупная мощность атак, берется небольшой запас и подбираются механизмы противодействия, чтобы и отдельного клиента защитить, и самим при этом не упасть.
Важно понимать, что любой типичный хостинг находится под DDoS-атакой практически 24/7: хоть одного клиента в каждый момент времени да атакуют. Поэтому DDoS для нас — это даже несколько банально. За 17 лет мы повидали много чего и в принципе знаем ключевые (и не только) паттерны, откуда, что, куда и как.
❯ Добрый вечер
14 сентября, ближе к 18:00, в нас влетел очередной DDoS, с которым известно что делать. Отбили — пошли отдыхать. И не успел я допить чай, как атака повторилась, потом опять, а потом еще раз. Каждый раз интервал уменьшался, а объем нарастал.
Скриншот от StormWall
Далее для любителей краткого изложения перечислю возникшую причинно-следственную связь по инфраструктуре.
В площадку наливается больше, чем та способна переварить → роутеры перегружаются вплоть до потери сигнализации → мы через OOB блокируем атаку через RTBH/FS или переключаем сеть на сторонний центр очистки трафика → цель атаки меняется в течение пяти минут.
Из дополнительных проблем в СПб: аплинки подключены через свитчи с переподпиской, QOS или не работает, или не хватает буфера → разваливается сигнализация. Дополнительно существуют громадные растянутые VLAN, из-за чего атака на одну подсеть затрагивает огромное количество клиентов. Мониторинг и контрмеры работают слишком медленно.
Иногда приходилось расставлять приоритеты
И в остальных локациях: нет своей сети, а ЦОДы нас блочат, защищая свою инфраструктуру. Когда сеть отдается напрямую с железок дата-центра, нет не то что возможности заблокировать атаку, затруднена даже идентификация паттерна: раз — и ноды отвалились. Из доступной информации только триггер в Заббиксе. Самые печальные моменты — когда у нас сутками лежало несколько локаций целиком и наглухо. Даже аплинки наших провайдеров в дата-центрах просто говорили, что мы не готовы это фильтровать, поэтому мы вас отключаем. Как атаки прекратятся, подключим обратно.
❯ Мы накидываем план
Первое: научиться блокировать хотя бы часть атаки на уровне маршрутизаторов провайдеров. Цель — снизить воздействие на клиентов, защитить инфраструктуру. Второе: научить нашу сеть переваривать всю аплинковую емкость без спецэффектов, параллельно ее расширяя.
По железу: разобрать кучу мелких маршрутизаторов и поставить шасси, расширить каналы или пересадить их напрямую на роутеры либо убрать переподписку. Параллельно: доработать DDoS-защиту до состояния, когда мы можем блокировать атаку быстрее, чем это заметят клиенты, на которых не идет паразитный трафик.
И стратегически: построить свои сети во всех локациях. И собственную защиту.
В первую очередь отказываемся от существующей системы подавления DDoS, потому что она приносит больше вреда, чем пользы. Сетевики начинают спать по очереди, текущий flow-мониторинг меняем на семплированный Inline IPFIX с payload-ом. Таким образом не ждем, пока соберется поток, и принимаем решения за секунды. Этот шаг помог уменьшить среднее время обнаружения каждой атаки: чтобы понять, что она началась и как нужно действовать, нам сначала нужна была пара минут, чуть позже — 15 секунд, а сейчас автоматика реагирует почти мгновенно.
Рабочая обстановка
Изначально управление было ручным, чуть позже принятие решений стало автоматизированным: мониторинг научился блокировать DDoS сразу же после обнаружения. В итоге за период с 14 по 20 сентября мы заблокировали более 20 тысяч отдельных паттернов.
В это время по всем каналам — в телеге, в соцсетях, в тикетах — клиенты переживали, ругались и задавали вопросы. И я их прекрасно понимаю. Кстати, о прекрасном:
Дорабатываем защиту: делаем ее быстрее, технологичнее, чтобы принимала максимально правильные решения. Разбираем всю старую архитектуру и избыточные куски сети — все под нагрузкой и идущими атаками и так, чтобы воздействие на клиентов было минимальным. Примерно в это же время атакующие понимают, что мы что-то сделали, поэтому меняют паттерны. Мы стали получать мощные краткосрочные волны трафика, на которые не успевала реагировать ни наша программа, ни большинство предлагаемых на рынке защит: заливало настолько разнообразно и быстро, что наши стыки и некоторые обменники начали складывать в нас сессии по prefix-limit. В эти периоды бывало и такое:
❯ Строим свою сеть
Начинаем с Питера. План включал в себя апгрейд маршрутизатора с установкой дополнительных плат и подключение к различным каналам и точкам обмена трафиком. Цель — увеличить пропускную способность: нам нужно было научиться принимать трафик атак и блокировать более точечно, а не просто кидаться блекхолами и снимать префиксы. Кроме того, стало понятно, что объемы атак могут расти и нам нужно будет научиться расширять емкость более оперативно, не проходя весь цикл «найти железо → найти емкость → собрать».
Главный роутер в СПб. На скрине MX480 в составе 2xSCBE2, 2xRE-S-2X00x6, 4xMPC7E MRATE
Обычные маршрутизаторы не всегда эффективны для такой деятельности: они обладают слишком сложным и дорогим конвейером обработки трафика, предназначенным для других задач. Исходя из этого мы решили действовать комплексно: помимо расширения каналов и увеличения портовой емкости сервисных и пограничных маршрутизаторов начали внедрять пакетные платформы на базе Juniper PTX. Они хоть и попроще, но в них много дешевых 100G/400G-портов, как раз то, что нам нужно.
Благодаря хорошим отношениям с поставщиками мы смогли быстро найти сетевое оборудование: поставка заняла всего полтора месяца. Для техники такого класса это очень быстро.
В итоге в Питере мы добили емкость по основным направлениям до 500+ гбит, а по автономке у нас сейчас суммарно около терабита. Уже через две недели после этого ситуация в СПб стабилизировалась: емкости хватало, фильтры отрабатывали оперативно. В остальных локациях сеть была арендованная: и в Казахстане, и в Европе. По этой причине параллельно с выравниванием ситуации в Питере у нас появилась новая приоритетная задача: поставить в заграничные локации собственные маршрутизаторы и дотянуться до них из Питера — тянуться решили через M9.
Девятка до сих пор крупнейшая пиринговая точка и сосредоточение телеком-инфраструктуры РФ и СНГ. Кроме основных трасс для всей России, туда же заходят каналы от СНГ — зачастую единственные.
Магистральные каналы между площадками дают несколько преимуществ:
Возможность отправлять и получать трафик через любые другие стыки Таймвеба во всех странах.
Возможность предоставлять клиентам дополнительные сервисы в виде каналов связи.
Наше управление не развалится никогда, даже если внешние стыки в локации будут забиты под полку.
Собственно, начинаем с Казахстана. Протянули канал до девятки и пустили трафик уже через свою сеть.
MX204 на девятке, собирает магистрали и внешние линки. Скоро заменим его 960-м и будем забивать сотками
Кстати, с доставкой в Казахстан повезло не с первого раза. На казахской таможне менялся состав — и все встало мертвым грузом. Ситуацию решили творчески: отправили одного из наших сотрудников везти 204. Забавно, что изначально мы собирались отправлять MX104 — довольно старую и давно снятую с поддержки платформу, которой, впрочем, с запасом хватает на нужды этой площадки.
MX104 со склада — кусочек истории телекоммуникаций
Но из-за ее громоздкости отправили 204 — и теперь в казахстанском ЦОДе у нас стоит платформа, которой хватит на целый машинный зал облака, а не на наши несколько стоек. На память осталась только фотка со стикером из аэропорта Екб:
К декабрю дотянулись и в Европу: теперь у нас есть узлы во Франкфурте и Амстердаме с арендованной магистральной емкостью. Там появились выходы и в интернет — через Tier-1 операторов, и на европейские обменники.
Следующий логичный шаг — перевели площадки в Амстердаме и Польше на свою сеть. Теперь нас никто не отключит в случае атак, как бонус — интернета стало больше и появились выделенные каналы для клиентских выделенных серверов, скоро будут и во всем Клауде. В итоге вы сможете не только заказать себе сервер с 10G-интернетом, но и расширить локальную сеть до любой нашей точки присутствия — с гарантированной полосой и любыми удобными вам настройками.
Раз уж пошли по локациям, то добавлю, что в этом году запустились и в Москве, в IXcellerate. Это Tier-3 с уникальной системой охлаждения по типу «холодная стена». Я там был на экскурсии — наверное, самое интересное, что я видел в России и СНГ, а поездил я немало. Пиво еще вкусное у них было — тоже плюс 🙂
Москва, кстати, у нас сразу же запустилась с нормальной архитектурой: широкие линки на стойку, 200G до девятки, масштабируемый слой агрегации. По умолчанию даем на все виртуальные серверы по гигабиту в секунду вместо 200 мегабит, на всех дедиках доступно 10G/40G по запросу. В результате, если клиентам это необходимо, мы можем дать гораздо больше емкости, чем могли бы в Петербурге еще полгода назад.
2xQFX5120-32C в IXcellerate
❯ Почему мы не спрятались за подрядчиками
На самом деле мы обращались к нескольким компаниям, но на тот момент уже стало понятно, что у нас не получится использовать их как общее средство защиты для всей сети.
Решения по комплексной защите от DDoS, по сути, делятся на два вида: это готовые решения, устанавливающиеся непосредственно на сети компании, и сторонние центры очистки трафика, через которые этот самый трафик нужно пропускать. На тот момент у нас существовали собственные чистилки и был опыт постройки подобных решений. Посоветовавшись с коллегами по цеху, решили двигаться именно по такому сценарию: принимать трафик → очищать большие потоки на уровне сети, привлекая центры очистки в отдельных случаях → заниматься тонкой очисткой с помощью вендорских решений.
Важно отметить, что при использовании внутренних решений для защиты от DDoS необходима сеть, способная обрабатывать и фильтровать трафик, не затрагивая других клиентов или локации. То, что отфильтровать не удалось, должно быть направлено на системы тонкой очистки с минимальной задержкой и воздействием на чистый трафик.
Необходимо было сначала усовершенствовать сеть до этого состояния, а затем заниматься внедрением коробочных решений. Мы переводили атакуемые подсети в партнерские центры очистки, хоть иногда это больше аффектило на нормальный трафик, чем помогало.
Такое положение дел было связано с характером самого трафика и с тем, что атаки были короткими и частыми: классифицировать «чистый» трафик в подсети, состав серверов которой меняется от недели к неделе, если не чаще, — малореально. А переключить маршрутизацию за время между атаками часто и вовсе не получается: цели меняются быстрее, чем BGP-апдейты распространяются по интернету.
❯ Что сейчас
Подобные атаки прилетают, но в целом мы научились их фильтровать: чистить на уровне сетевого оборудования или деприоритизировать/блокировать клиента, если объем превышает пороги.
Работы еще много: всю эту новообразовавшуюся сеть нужно резервировать и расширять. На М9 мы взяли целую стойку и собираемся ставить шасси MX960 — с большим запасом на будущее. Оно будет выполнять роль магистральной развязки, принимать внешние стыки и выступать ядром сети дата-центров по Москве, у нас там большие планы. Не забываем и про Северную столицу: платформа PTX10003 станет ядром нового узла на Кантемировской («Радуга»), где будет перемыкать магистрали и стыки с внешними сетями, выступая частью инфраструктуры очистки трафика в Санкт-Петербурге.
Находимся на этапе тестирования с Servicepipe: будем пробовать систему уже тонкой очистки трафика — если атака на клиента не угрожает инфраструктуре, не полностью все блокировать, а принимать трафик атак на себя и отдавать клиенту уже очищенный, вплоть до L7.
Много работы будет по пирингам: думаем, что скоро мы сделаем прямые подключения к Google, AWS, Azure и другим гиперскейлерам. Хотим организовывать серьезные продуктовые преимущества для наших клиентов: если ваш продукт требует очень хорошей связности с мировыми облаками или у вас мультиклауд — мы сможем обеспечить как хорошую связность по интернету, так и выделенные линии, если потребуется.
Для выделенных серверов по части сети у нас получилось очень интересное предложение. По запросу скорости мы даем вплоть до 100—200 гигабит на сервер, так мало кто умеет. Кроме простого интернета — широкий набор сетевых решений: тут и более-менее стандартные L2/L3 VPN на MPLS, и любые манипуляции с внешней маршрутизацией. Для владельцев своих AS соберем транзит, притянем любую популярную точку обмена трафиком. Для тех, кто хочет ими стать, — поможем выпустить ASN, арендовать или купить сети, анонсировать их в мир.
Глобально у нас были компетенции, ресурсы и возможность их тратить на инвестиции в сеть, были контакты и налаженные взаимоотношения с огромным количеством людей. Все это очень сильно нам помогло.
❯ И напоследок — неудобный вопрос от маркетинга
— Почему не начали делать все это раньше, а триггером стало то, что на нас пришла атака?
Расширение в целом планировалось, Таймвеб всегда делал упор на качество сети, но процесс шел постепенно. Исторически мы сфокусировались на нашем центральном хабе в СПб, а стройка в остальных локациях планировалась по мере их расширения.
А почему атаки стали триггером? Все банально. Во-первых, мы поняли, что начали расти сильно быстрее, чем планировали. Стало понятно, что нужно больше емкости, больше сервисов — и не когда-то, а сейчас. Во-вторых, появились новые угрозы, которые не отражаются стандартными средствами. В какой-то момент мы переросли «стандартные» подходы, которые мог бы использовать игрок меньшего размера, — нужно было пилить какой-то кастом или средствами сторонней компании, или самостоятельно. Мы выбрали второе.
Атаковали не только банк, но и все сервисы экосистемы
В конце января Сбербанк подвергся «очень длительной» DDoS-атаке, которая длилась четыре дня, рассказал зампред правления банка Станислав Кузнецов на форуме «Кибербезопасность в финансах». Он заверил, что сервисы Сбера и сам банк эту атаку выдержали.
«С 24 по 28 января выдержали очень длительную четырехсуточную DDoS-атаку. Она была весьма сложной — видоизменялась десятки раз за эти четверо суток. Были атакованы одновременно все 1100 сервисов Сбера». — сказал он.
По его наблюдениям DDoS-атаки в последнее время изменились — их стало меньше по количеству, но изощренность растет, указал он и предложил объединиться крупным банкам в борьбе с хакерами.