Инженер-программист Дэнни Го рассказ, что его кошка вовремя разбудила спящего хозяина, тем самым предупредив о DDoS.
Несколько лет назад Го работал в стартапе, в нем не было дежурства за работой сайта. Это было осознанное решение компании, тк быть на дежурстве сложно, а команда и так справлялась, следя за срочными сообщениями.
Только работает схема днем, а ночью никто за сайтом никто не следит, по причине сна.. (вспоминается советский анекдот про полет на солнце ночью)
Около трёх часов ночи я проснулся от того, что моя кошка вылизывала мне волосы. Само это действие не было чем-то необычным. Время от времени она делала это, и я оптимистично воспринимаю это как знак того, что я ей действительно нравлюсь, а не того, что она просто меня терпит. Но за 9 лет это был единственный раз, когда она сделала это, пока я спал. Я проверил свой смартфон, чтобы узнать, который час, и заметил, что пару минут назад сработало предупреждение AWS CloudWatch из-за неработоспособных сервисов нашего балансировщика нагрузки.
Я пытался зайти на наш сайт со смартфона, но он не загружался. Я начал проверять логи на рабочем ноутбуке. Наша панель мониторинга показала огромное количество запросов, поступающих со многих IP-адресов, связанных с разными странами. Да и международный трафик для нас не был типичен, поскольку наши сервисы были доступны только жителям США. Это была распределённая атака типа «отказ в обслуживании» (DDoS).
Моей первой и не самой удачной мыслью было заблокировать IP-адреса на уровне сервера, что было бы утомительно и, возможно, неэффективно, если бы у злоумышленника было значительно больше исходных IP-адресов. Но потом я вспомнил, что мы уже настроили брандмауэр веб-приложений AWS. Чтобы справиться с немедленным сбоем, я установил правило блокировки запросов из других стран. Оно вступило в силу и в течение следующего часа заблокировало сотни тысяч запросов. Наш сайт снова заработал, поток запросов прекратился.
Позже тем же утром в команде заметили, что получили электронное письмо в нашу службу поддержки примерно в то время, когда началась атака. Отправитель, используя ужасную грамматику, заявил, что нашёл уязвимость на нашем веб-сайте, приводившую к сбою Apache, которую мы не устранили. Злоумышленник угрожал, что заблокирует наш сайт и сможет сохранять его в таком состоянии в течение нескольких месяцев. Он великодушно предложил нам «файл с решением», если мы отправим ему $5000 в биткойнах. Мы не ответили, хотя, оглядываясь назад, можно сказать, что было бы забавно попытаться его троллить.
«Мне до сих пор трудно поверить, что моя кошка разбудила меня в идеальное время. Вы можете предположить, что предупреждение AWS заставило мой телефон вибрировать или издать звук, разбудив первым мою кошку. Но ночью я держу телефон в режиме «Не беспокоить». Так что мне просто нравится думать, что каким-то образом она почувствовала, что что-то не так, и это не могло подождать до утра. Это был, конечно, более приятный способ проснуться, чем рёв будильника», — подытожил Го.
Отсюда вывод, что кошки чувствуют электромагнитные волны, исходящие от телефона)
И когда у нас будет сайт заведем дежурную кошка, сэкономив на дежурстве.
Этот материал должен был выйти в декабре 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, арендовать или купить сети, анонсировать их в мир.
Глобально у нас были компетенции, ресурсы и возможность их тратить на инвестиции в сеть, были контакты и налаженные взаимоотношения с огромным количеством людей. Все это очень сильно нам помогло.
❯ И напоследок — неудобный вопрос от маркетинга
— Почему не начали делать все это раньше, а триггером стало то, что на нас пришла атака?
Расширение в целом планировалось, Таймвеб всегда делал упор на качество сети, но процесс шел постепенно. Исторически мы сфокусировались на нашем центральном хабе в СПб, а стройка в остальных локациях планировалась по мере их расширения.
А почему атаки стали триггером? Все банально. Во-первых, мы поняли, что начали расти сильно быстрее, чем планировали. Стало понятно, что нужно больше емкости, больше сервисов — и не когда-то, а сейчас. Во-вторых, появились новые угрозы, которые не отражаются стандартными средствами. В какой-то момент мы переросли «стандартные» подходы, которые мог бы использовать игрок меньшего размера, — нужно было пилить какой-то кастом или средствами сторонней компании, или самостоятельно. Мы выбрали второе.
Одна из разновидностей UDP Flood, которая направлена на DNS сервис.
В время атаки DNS Flood направляется огромное количество DNS запросов с очень широким диапазона IP-адресов.
Сервер-источник атаки не в состоянии определить, какой из пакетов пришел от реального клиента, а какой нет, и отвечает на все запросы.
В результате чего, DNS Flood занимает все сетевые ресурсы и полосу пропускания DNS-сервера, вызывая его отказ.
DDoS-атаки: пакеты данных организованы таким образом, чтобы они выглядели идентичными настоящимDNS запросам. Эту атаку невозможно обнаружить с помощью подробного анализа, поскольку каждый запрос выглядит обычным. С использованием широкого спектра атакующих IP-адресов злоумышленник без проблем может обойти большинство алгоритмов, предназначенных для обнаружения необычного трафика.
Информация предоставлена в ознакомительных целях! Мы в телеграме!
Выспаться, провести генеральную уборку, посмотреть все новые сериалы и позаниматься спортом. Потом расстроиться, что время прошло зря. Есть альтернатива: сесть за руль и махнуть в путешествие. Как минимум, его вы всегда будете вспоминать с улыбкой. Собрали несколько нестандартных маршрутов.
DDoS (Distributed Denial of Service) - это тип кибератак, при котором злоумышленники пытаются насытить доступные ресурсы (например, веб-сайт или сеть) трафиком, который превышает их возможности, чтобы они перестали работать или стали недоступны для обычных пользователей.
DDoS-атаки обычно проводятся с помощью ботнетов, т.е. сетей компьютеров, зараженных вирусами или вредоносными программами, которые контролируются злоумышленниками. Они могут использовать различные методы, такие как UDP-флуд, ICMP-флуд, SYN-флуд, чтобы перегрузить сетевые ресурсы и сделать их недоступными.
DDoS-атаки могут привести к серьезным проблемам, таким как отключение сайтов, потеря данных и денег, а также ухудшение репутации компании. Поэтому организации обычно принимают меры защиты от DDoS-атак, такие как использование специального оборудования и программного обеспечения, которые позволяют обнаруживать и блокировать такие атаки.
UFONet-злоупотребляет OSI layer 7 HTTP для создания / управления «зомби» и проведения различных атак с использованием; GET/ POST, многопоточность, прокси, методы подмены происхождения, методы уклонения от кэша и т. д.
Если бог нематериален и действительно существует в качестве некой вычислительной системы, а молитвы - своеобразные запросы, то можно ли утверждать, что священники - хакеры, которые дудосят систему?
Заходишь на Пикабу полистать ленту, а вместо этого бесконечная загрузка или сообщение с ошибкой. Бывало? Если с интернетом все в порядке, то, возможно, веселье испортила мерзкая DDoS-атака. Так кто же «роняет» Пикабу и зачем? Опросили разрабов и всех причастных: рассказываем, как DDoS-ят наш сайт и какие есть способы защититься.
Кто DDoS-ит Пикабу, как часто и зачем
Шок-контент: мы фиксируем DDoS-атаки на Пикабу каждый день! Но крупные, которые способны «уронить» сайт, происходят один-два раза в месяц. Кто их устраивает, неизвестно — виновники не представляются.
Для справки, DDoS (denial-of-service — «отказ в обслуживании») — это когда некие злодеи «нападают» на сайт, чтобы на время вывести его из строя или сильно затормозить.
Для чего хакерам DDoS:
1. Прямое вымогательство: «Выполните наши требования, и мы перестанем атаковать».
2. Бизнес-интересы: «Положим сайт конкурента во время черной пятницы — и все покупатели утекут к нам».
3. Демонстрация силы третьей стороне: «Сейчас я положу какой-нибудь сайт, смотрите!», «С вашим конкурентом мы точно справимся, вот доказательство».
4. Прикрытие для другой атаки: «Отвлечем DDoS-ом, а сами параллельно хакнем сайт».
В анти-DDoS практике Пикабу бывали случаи, когда злоумышленники прибегали к шантажу. Но у нас есть железное правило: мы игнорируем любые требования, связанные с угрозами или причинением целенаправленного вреда сайту.
А еще атаки заказывают конкуренты. Впрочем, это ожидаемо — DDoS уже давно продается как услуга, и в последние годы достаточно доступная. В противовес этому многие хостеры — компании, которые хранят данные сайтов на площадках-хостингах, — предлагают защиту от атак для бизнеса.
Иногда через DDoS «сигналят», призывая удалить из ленты конкретный контент. Наш главный инженер-архитектор рассказал, что однажды на Пикабу больше недели в одно и то же время атаковали пост на политическую тему — намекали, что его нужно убрать с сайта.
Бывает и наоборот: с помощью DDoS хотят запустить вирусное распространение информации. Последний раз такое произошло на Пикабу в феврале: два дня подряд массированные атаки мешали войти на сайт. Нам даже пришлось временно ограничить доступ нашему ресурсу из некоторых стран, но в итоге все закончилось благополучно.
Как работает DDoS
Злоумышленники искусственно вызывают перегрузку сервера, массово отправляя на него запросы. Представьте, что вы попали на вечеринку в маленькой студии, а туда уже пришло 100 человек — дальше входной двери двинуться сложно. С DDoS та же история: дойдя до пика нагрузки, сайт или сервер просто «падает», перестает отвечать на запросы. Привет, «отказ в обслуживании».
А помогают DDoS-атакам зомби. Но не те, что из фильмов, а виртуальные — компьютеры, зараженные вирусом. По команде хакера орды из тысяч таких зомби-ПК начинают одновременно нападать на «жертву». Причем их владельцы чаще даже не в курсе, что участвуют в DDoS, — пользуйтесь антивирусами!
Как пытаются ломать Пикабу
Чаще всего мы сталкиваемся с DDoS-атаками третьего (L3) и четвертого (L4) уровней, реже — седьмого (L7). Похоже на ранговую систему прямиком из аниме, но это реальные термины по сетевой модели OSI, которую хостинги и специализированные сервисы используют при DDoS-защите.
Атаки третьего и четвертого уровня чаще всего используются для одной цели — забивание канала сайта и его «обрушение». L3 — это когда злоумышленники нагружают сервер так, что блокируются все порты. При L4 нарушают передачу данных от отправителя к получателю. Уровни L3 и L4 встречаются на Пикабу не слишком часто, но от таких атак можно ожидать рекордных цифр ширины атаки канала и количества пакетов в секунду (для тех, кто в теме).
В последнее время на Пикабу стало больше атак L7, цель которых — «деградация» веб-приложения, что чаще всего приводит к забиванию CPU / RAM на сервере. Защита в этом случае требует специальной подготовки сайта и больших мощностей хостера.
Самая необычная такая атака на Пикабу произошла в марте этого года. Тогда нас больше недели испытывали на прочность через L7 с постоянно увеличивающейся нагрузкой. Среднечасовой пик атаки превышал 300 000 запросов в секунду, а секундные пики — 500 000. Закидывали запросами широкой бот-сетью, подключали вредоносные скрипты в рекламные модули.
Как на Пикабу защищаются от DDoS
Сколько мы ни допытывались у руководителя отдела разработки Пикабу, раскрыть все карты по теме защиты от DDoS-атак он отказался — секрет фирмы :) Но кое-что он и его коллеги все-таки рассказали. Делимся из первых уст.
Не будем юлить: на Пикабу мы защищаемся от DDoS так же, как и большинство интернет-ресурсов. Пользуемся услугами нескольких крупных партнеров, которые специализируются на защите от такого рода атак.
Само собой, у нас есть план по отражению DDoS, а еще проводится постоянный анализ нагрузки на сервера. Если мы видим, что сайт Пикабу атакуют, то сразу уведомляем всех причастных и переходим к защите.
Внимание, дальше абзац на айтишном! На Пикабу от DDoS обороняются на разных уровнях: от слоя самого конечного сервера до внешних анти-DDoS решений в разрыве между клиентом и конечной инфраструктурой нашего сайта. Быстро отразить атаку помогает усиленный режим защиты на одном из слоев.
Было бы классно написать, что для нас справиться с DDoS дело пяти минут — но это не так. Каждая атака уникальна, требует вдумчивого анализа происходящего и аккуратного реагирования.
Поэтому если вы пикабушник и видите, что сайт Пикабу вдруг «упал», — наберитесь терпения. Просто знайте — мы делаем все, что в наших силах, для вашей защиты ^_^
Хостинги и защита от DDoS
Некоторые хостинги предлагают свою защиту. У всех она разная, со своими плюшками. Анти-DDoS можно построить на любом хостинге, но все зависит от ресурсов — чтобы отразить сильную атаку, нужны большие мощности.
Напоследок расскажем, какие на Пикабу требования к хостингам. Нам их поведал сисадмин, ну а мы поделимся с вами. Вдруг решите запустить свой сайт или расширить бизнес — пригодится!
• SLA на устранение инцидентов и решение технических вопросов.
• Наличие собственной облачной инфраструктуры.
• Гибкое управление сетью с возможностью организации различных нетиповых сетевых конфигураций.
• Современное оборудование и возможность замены вышедших из строя компонентов за счет новых поставок.
Защита от DDoS — это специальная услуга, которая требует специальных компетенций и оборудования. У хостинга FenixHost есть все вышеперечисленное и не только. Клиентам доступна быстрая безлимитная сеть 10 Гбит/с, свое оборудование HP Enterprise, выделенные и облачные серверы, сетевое хранилище, построенное на RAID-10 дисковых массивах и другие услуги. Настройка серверов занимает не больше 20 минут, а отзывчивая техподдержка работает 24/7.
Если вы владелец сайта, разработчик или сисадмин, который ищет провайдера для размещения своих и клиентских сайтов, самое время подумать о безопасности вашего ресурса. На FenixHost сейчас действует акция: юрлица могут пользоваться сервером первый месяц бесплатно.
Кибервойна идёт в самом разгаре DDoS-атаки на WEB сервисы идут регулярно и мне надоело наблюдать о бравировании наших партнёров их "достижениями". Собственно моё решение не позволит на 100% отразить атаку, но по крайней мере не даст Вам захлебнуться. https://github.com/bakup/Serpentarium
IP адреса из списка были добыты из журналов работ доступных мне web сервисов, а так же из сторонних источников. С февраля была всего одна жалоба на блокировку, после чего я поправил анализатор и с тех пор жалоб не было.
Базу IP адресов буду обновлять регулярно.
Не все могут в Web Application Firewall, по этому если кому я смогу помочь отразить DDoS-атаку, значит буду спать крепче.
Кстати, может кто подскажет open-source WAF, который используют в проме?
И ещё вопрос, может кто знает как идентифицировать VDS/VPS сервер? С них так же осуществляют атаки.