Мы в HOSTKEY много лет используем блоки питания HP Common Slot мощностью от 460 до 1400 Вт. Они эффективны, надежны в эксплуатации и легко интегрируются с серверами различных производителей. Если у вас скопились ненужные серверные корпуса, не торопитесь сдавать их в утиль: есть шанс сэкономить €500 – €600 на покупке новой платформы.

Впервые стандартные блоки питания Common Slot появились примерно в 2010 году в Proliant G6 и в большинстве остальных серверов HP того времени. Эти массовые устройства стоят на eBay/AliExpress крайне недорого (€20 – €50 за штуку), а на Авито — приблизительно ₽5000 – ₽6000. Как правило блоки питания исправны: случаи их выхода из строя или смерти при включении наблюдаются крайне редко. Нет проблем и с оптовыми партиями: мы покупаем более 100 штук за раз.

Блоки питания Common Slot работают тихо: при малой и средней нагрузке их шум теряется за шумом обычного компьютера. При полной нагрузке маленький вентилятор издает характерный громкий визг на 65 дБ (впрочем, в ЦОД он не слышен). Сайт HP содержит мало информации по спецификациям: схему использования и распиновку там найти невозможно, но есть подозрительно похожее устройство Murata Power Solution другого производителя. На его сайте обнаружились нужные нам документы, включая подробные мануалы для блоков питания на 460 Вт и на 1600 Вт. В сети также доступны результаты исследований энтузиастов, видимо HP Common Slot пришлись по вкусу не только нам.

О чем пишут хакеры?

• Эффективность HP Common Slot при средней нагрузке составляет 92 – 94%.
• Для включения нужно соединить пины 36 (Power Supply Present Signal — короткий пин) и 37 (12V Standby Output) на шине через резистор примерно на 22 кОм, чтобы БП решил, будто он вставлен в слот, а пин 33 (Power Supply on/off control signal — крайний справа) подключить к защитному проводнику (заземлить).
• До восьми HP Common Slot могут работать параллельно.
• Для включения БП параллельно нагрузке никаких специальных действий не требуется: основная нагрузка отдельно, линии Vsb — отдельно (см. таблицу в документации Murata Power Solution).
• В БП есть интерфейс I2C и аналоговый выход индикации мощности (60,15 мВ/А).

Как этим воспользоваться?
Самый простой вариант — купить на AliExpress или в другом онлайн-магазине готовую распределительную плату такого типа:

Или немного другую:

Обратите внимание, что на первой плате есть кнопка включения — будет неудобно, если убрать ее в корпус сервера. На второй плате установлен переключатель, который можно включить и больше не трогать. Цена вопроса — примерно €9.

Если нам не нравятся готовые платы, можно сделать собственную. Для этого потребуется разъем питания производства Wingtat модели 2.54 EDGE SLOT DIP 180° SINGLE LEAF TYPE WITHOUT EAR High Power S-64M-2.54-5 slots. Компания быстро реагирует на запросы и отправляет заказы на 50+ разъемов примерно по $2 за штуку. В рознице они есть на AliExpress. Если предполагается использовать блок питания все 1200 Вт, плату лучше заказывать с медью повышенной толщины. Паять разъем на ней стоит феном и тонким припоем с флюсом: так получается быстрее всего, обычный паяльник подобные платы нормально не берет.

Мы используем платы примерно такого дизайна:

Схема доступна в нашем репозитории на GitHub. На разъеме J1 можно измерить напряжение и понять текущую нагрузку на блок питания — 60,15 мВ на каждый ампер мощности по шине 12 В.

Готовый экземпляр:


Как это выглядит на сервере?

Мы часто используем универсальные корпуса Supermicro и во многих из них уже нет выбывших из строя или модернизированных под новые материнские платы оригинальных блоков питания. Искать родные БП нецелесообразно, поскольку они дорогие и такие же поношенные.

В этом случае родной блок питания пришел в негодность и был заменен на универсальный HP Common Slot мощностью 750 Вт. Лишнее мы обрезали и закрепили блок в корпусе на двухсторонний монтажный скотч. Для преобразования 12 В в необходимое для работы ATX24 напряжение используются родные PicoPSU или их китайские аналоги. На фото сервер на Supermicro H11DSi с двумя процессорами AMD Epyc и потреблением около 400 Вт. С китайскими аналогами он категорически отказался работать, а родная PicoPSU не влезла по высоте и была включена через переходник. Питание процессоров включено напрямую, это ничему не мешает.


Вид сзади. Блок питания немного не влез по ширине, но на скорость и удобство эксплуатации это не влияет.


Зачем это нужно?
Мы экономим на новых платформах примерно €500 – €600. Это позволяет держать стоимость аренды выделенных серверов на рыночном уровне, плюс мы не выбрасываем старые корпуса в утиль со всеми вентиляторами и бэкплэйнами, чтобы зря не загрязнять окружающую среду.

По надежности: обычно блок питания выходит из строя при первом включении. У нас для этого есть специальный тестовый стенд с автоматом категории А на 5 А. Если БП включился, дальше он будет работать годами. Выход из строя БП подобного класса при эксплуатации в ЦОД на нашем парке из нескольких тысяч машин происходит примерно раз в полгода, как правило при модернизации оборудования. PicoPSU в обычных серверах из строя практически не выходят.

Попробуем использовать блоки питания парой и соберем для этого тестовый стенд на базе нашего сервера.


Здесь два блока питания с нашими переходными платами подключены параллельно. Платы соединены между собой прямыми проводами-удлинителями GPU. Пара кабелей по 3 провода в каждом обеспечивают перемычку как раз на 400 Вт (на пределе). Важно, чтобы соединительные кабели были качественными: нужного сечения и хорошо обжатыми (у нас как раз такие). Для пущей надежности на 400 Вт нужна перемычка из трех кабелей по 3 провода. Процессоры подключены каждый в свой блок питания.

Это действительно работает?
На видео мы запустим Linpack на сервере с обеими подключенными блоками питания и будем под нагрузкой отключать их от сети по очереди, включая обратно через некоторое время. Мы убедимся, что напряжение остается в норме и сервер не перезагружается под стресс-тестом. Нагрузка по данным сервера — около 400 Вт под стресс-тестом на процессорах, значит из сети уходит около 500Вт.

Как видите, схема рабочая: кабели и разъемы не греются, все функционирует в штатном режиме и без родных для сервера блоков питания. Поскольку HP Common Slot предназначены для работы парами, в них есть вся защита и блокировки.

Почему нужно использовать два БП?
Многие думают, будто избыточность нужна для отказоустойчивости: если при эксплуатации сервера в ЦОД один блок питания сломается, второй обеспечит работу. Это мнение отчасти правильно, но есть и другие нюансы.

Часто при выходе из строя блока питания выбивает автомат в ПДУ или в щитке (по короткому замыканию или по перегрузке). Если оба блока включены в одну ПДУ, избыточность не поможет. ЦОДы обычно устроены так, что в стойку приходят два не пересекающихся между собой луча питания. У них разные распределительные шкафы, они идут к разным ИБП, а эти ИБП подключены к разным трансформаторам и дизелям. Все это переключается с некоторой задержкой, а ЦОД гарантирует, что питание будет на одном из лучей всегда, но не на обоих одновременно.

Важно, чтобы у сервера было два блока питания, или придется использовать стоечный АВР — довольно дорогое устройство с твердотельным быстродействующим реле, которое может быстро и незаметно для нагрузки переключаться между несинхронизированными по фазам вводами.

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

У нас в HOSTKEY был освобожденный клиентом сервер с платой SuperMicro и процессором AMD EPYC 7551, коробка регистровой памяти DDR4 разной скорости и пара часов свободного времени. Ничто не мешало посмотреть, как зависит производительность машины от количества установленных планок.

Тестовый стенд
Двухпроцессорная материнская плата SuperMicro H11DSi имеет 16 слотов памяти и стоит 63400 рублей в «Регарде» или от €700 в Нидерландах (по июньским прайсам 2022 года). Есть несколько ее модификаций: Rev 1 поддерживает память до 2666 МГц, а Rev 2 — до 3200 МГц (это важно). В плату можно установить стик М2 NVMe безо всяких переходников или 6 таких стиков с переходниками.



Разумный максимум памяти для SuperMicro H11DSi составляет 16х64=1024 ГБ, а модули 16/3200 в Европе стоят около €100 (в Москве, по данным regard.ru, их цена составляет примерно 15000 рублей). Модули на 32 и 64 ГБ стоят пропорционально дороже: €200 (30000 рублей) и €400 (65000 рублей). Более медленная память на 2133 МГц стоит в два раза дешевле: примерно €50 евро на eBay и Авито.

Процессор у нас старый, еще первого поколения (32 ядра на 64 потока, 2.0 ГГц базовой частоты с турбо до 3 ГГц). Такие стоят €250 на eBay из Китая и €350 в Европе с доставкой за пару дней уже с VAT. TDP процессора составляет 180 Вт, что еще позволяет эксплуатировать его в ЦОД с одноюнитовыми корпусами и блоками питания на 500 – 600 Вт. Если TDP будет чуть выше, придется ставить корпус на 2U и активные радиаторы.

Приступаем к проверке
Давайте посмотрим, что получится, если в нашу плату установить 1, 2, 4 или 8 модулей памяти. Что будет, если установить второй процессор? Память для тестов мы взяли старую: одноранговые планки на 8 ГБ (2133 МГц) и чуть более новые двухранговые на 16 ГБ (2666 МГц). Модули на 3200 МГц наш процессор не тянет, поэтому использовать их придется с максимальной для EPYC 7551 частотой в 2666 МГц.


Тестировать будем на скорую руку с помощью Passmark и Linpak Extreme в режиме замера производительности, что довольно точно отражает производительность системы и ее стабильность.

Тест №1: 1 процессор, 8 модулей



Система показывает 181 Гфлопс на коротком тесте и около 19000 единиц Passmark: примерно на уровне современных i9-10900 и несколько больше чем у i9-9900K с 8 ядрами и 4 ГГц частоты. Неплохо для процессора 2017 года, который можно купить за €250.

Тест №2: 1 процессор, 4 модуля на 2133 МГц




Видно, что результаты странные: нам пришлось их перепроверить, но цифры во всех итерациях были одинаковыми. Linpak Extreme падение производительности процессора на 5% и производительности памяти на 10%, а синтетика Passmark дала 27500 — где-то на уровне Xeon Gold с 22 ядрами.

Тест №3: 1 процессор, 4 модуля на 2666 МГц




Немного увеличив частоту памяти, мы получили 200 Гфлопс и 29809 единиц в Passmark. Память работает на 10% быстрее, тест быстрее на 25%. Неплохо.

Тест №4: 1 процессор, 2 модуля на 2133 МГц




Процессор показывает результаты чуть хуже чем с 4 модулями, но производительность памяти сильно деградировала (на 30%).

Тест №5: 1 процессор, 1 модуль на 2133 МГц



Я было подумал, не зависла ли машина под Linpak Extreme, но нет, просто она она еле шевелилась. Это явно аварийный режим работы — не надо так делать.

Тест №6: 2 процессора, 8 модулей памяти (по 4 на процессор)




Два процессора работают быстрее чем один, но не кратно: 260 Гфлопс и 50000 в Passmark — это отлично за €700 Евро. Для достижения подобного результата на Intel потребуются два новеньких Xeon Gold 6242R по €3000 за каждый.

Тест №7: 2 процессора, 4 модуля памяти (по 2 на процессор)




Системе поплохело: мы сходу получили падение производительности на 15 – 20%. Не надо так.

Тест №8: 2 процессора, 2 модуля памяти (по 1 на процессор)




Не надо так, грустно смотреть.

Финальный тест: 2 процессора и полностью забитые модули




Система с шестнадцатью модулями памяти обеспечивает максимальную производительность: синтетические тесты в Passmark дают результат на 10% выше чем с восемью модулями, а Linpak Extreme показывает прирост на 40% — 370 Гфлопс против 260 Гфлопс. Ровно в два раза быстрее чем 1 процессор показал с 8 модулями памяти.



Итоги
Результаты получились немного неожиданными. Выяснилось, что меньше 4 модулей памяти на процессор в плату устанавливать не стоит, а 1 модуль ставить нельзя, даже если очень хочется. Разница в скорости памяти серьезно сказывается на производительности EPYC — не экономьте. Если не хотите сильно пожалеть, ставьте самые быстрые модули из тех, которые можно купить. Внимательно следите, чтобы материнская плата поддерживала высокие частоты (старые модели могут не потянуть 3000 МГц и выше).

Сегодня мы рады сообщить, что новый регион Google Cloud в Израиле открыт. Мы будем отмечать запуск на мероприятии в Тель-Авиве 9 ноября — зарегистрируйтесь, чтобы присоединиться к нам.

Израиль известен как страна стартапов и долгое время был центром технологических инноваций как для стартапов, так и для Google. Мы рады распространить этот инновационный подход на другие отрасли, ускоряя цифровую трансформацию, чтобы помочь создавать новые рабочие места и цифровые возможности, которые лучше обслуживают пользователей в Израиле. Согласно недавнему исследованию, проведенному по заказу Google, AlphaBeta Economics (часть Access Partnership) считает, что к 2030 году регион Google Cloud в Тель-Авиве внесет совокупный вклад в ВВП Израиля в размере 7,6 млрд долларов США и поддержит создание 21 200 рабочих мест только в этом году.

Регион Google Cloud в Тель-Авиве (me-west1) присоединяется к нашей сети облачных регионов по всему миру, предоставляя высокопроизводительные услуги с малой задержкой клиентам любого размера и из разных отраслей. Теперь, когда облачный регион Израиля является частью сети Google Cloud, он поможет местным организациям связываться с пользователями и клиентами по всему миру, а также будет стимулировать инновации и цифровую трансформацию во всех секторах экономики.

В прошлом году правительство Израиля выбрало Google Cloud для предоставления облачных услуг правительственным министерствам. Это партнерство может позволить правительству и частным компаниям, работающим в регулируемых отраслях, упростить способ обслуживания пользователей, создать единый подход к цифровой безопасности и поддерживать требования соответствия и резидентности.

За несколько лет мы расширили присутствие наших местных сотрудников Google в Тель-Авиве и Хайфе, чтобы поддержать растущее число клиентов и привнести культуру инноваций во все секторы экономики. От технологий, розничной торговли, СМИ и развлечений до финансовых услуг и государственного сектора ведущие организации выбирают Google Cloud как своего надежного партнера по инновациям.

С помощью Google Cloud мы меняем то, как миллионы людей читают и пишут, предоставляя наши собственные модели больших языков на основе самой передовой платформы графического процессора, которая предлагает непревзойденную производительность, доступность и эластичность

Ори Гошен, генеральный директор AI21 Labs

PayBox контролируется Банком Израиля и полностью размещен в облаке. Google Cloud предоставляет нам инструменты, необходимые для соблюдения нормативных требований и обязательств по безопасности, а также гибкость и оперативность для обслуживания миллионов клиентов, которые ежедневно полагаются на наше приложение

Дима Левитин, ИТ-директор, Paybox.

Израиль уже давно является центром технологических инноваций, и мы рады поддерживать таких клиентов, как AI21, Paybox и других, с помощью облака, которое им помогает:

Лучше понимать и использовать данные: Google Cloud помогает клиентам принимать более взвешенные решения с помощью единой платформы данных. Мы помогаем клиентам снизить сложность и объединить неструктурированные и структурированные данные, где бы они ни находились, чтобы быстро и легко получать ценную информацию.

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

Создайте среду для совместной работы. В современной гибридной рабочей среде Google Cloud предоставляет инструменты, необходимые для изменения того, как люди общаются, создают и сотрудничают.

Защитите системы и пользователей. Поскольку каждая компания переосмысливает свою систему безопасности, мы помогаем клиентам защищать их данные, используя ту же инфраструктуру и службы безопасности, которые Google использует для своих операций.

Построить более чистое и устойчивое будущее: с 2007 года компания Google придерживается нейтрального уровня выбросов углерода в своей деятельности, и к 2030 году мы работаем над тем, чтобы полностью перейти на безуглеродную энергию. Сегодня, когда клиенты используют Google Cloud – самое чистое облако в отрасли – энергия, которая питает их рабочие нагрузки, соответствует 100% возобновляемой энергии.

Мы рады видеть, что вы строите с новым регионом Google Cloud в Израиле. Узнайте больше о нашей глобальной облачной инфраструктуре, включая новые и перспективные регионы. И не пропустите презентацию в Израиле.

Пополняйте через QIWI-кошелек без комиссии

Регулярно наши клиенты пишут нам предложения по улучшению хостинга. Мы стараемся реализовывать все предложения по возможности, но самая ожидаемая нашими клиентами возможность, мы запускаем уже сегодня.

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

Заказывайте и продлевайте виртуальные и выделенные серверы уже сегодня через QIWI на hshp.host

DDoS и хостинг
Хостинг представляет из себя комплекс, состоящий из внутренней сети (автономной системы), пограничных маршрутизаторов и распределенных каналов связи с различными операторами связи.

Если упрощенно показать это на схеме, то получится следующее:

1. Операторы связи, обеспечивающие связь сети хостинга с внешним миром
2. Каналы связи с операторами
3. Пограничные маршрутизаторы
4. Каналы связи внутренней сети
5. Серверы хостинга (например, виртуального)

Целью DDoS-атаки является прекращение доступности какого-либо сервиса, будь то один сайт, сервер или даже целый хостинг. Что такое доступность сервиса? В контексте нашей темы это возможность конечного сервера хостинга получать весь легитимный трафик от пользователей, обрабатывать его за адекватное время и отдавать пользователям ответы. Поэтому для упрощения можно сказать, что мы должны обеспечивать хождение легитимного трафика в направлении 1-5-1.

PS: На самом деле, де-факто наша ответственность перед пользователями не заканчивается на том, что мы отдаем трафик операторам связи, т.к. бывают случаи, что даже при этом ответ до пользователя не доходит, но мы пока оставим эти кейсы за рамками нашей статьи.

Почему хостинг не может взять и полностью передать защиту от DDoS специализированным компаниям?

Передача данных в современной сети Internet построена на многоуровневой архитектуре, где каждый уровень несет свое определенное предназначение. Для передачи данных, используется стек протоколов TCP/IP, который построен по принципу эталонной модели OSI. Концепция этой модели заключается в разбиении процесса передачи данных на уровни, где каждый уровень отвечает за свой функционал.

В случае с DDoS атаками, их принято делить по уровням модели OSI, несмотря на то что стек протоколов TCP/IP состоит всего из 4х уровней.


Сами DDOS атаки происходят только на уровнях L3,L4,L7 по модели OSI.

Для защиты на уровне L3-L4 мы 24/7 работаем через специализированный сервис защиты, который постоянно отбивает сотни атак в день, в последнее время достаточно больших. По объему трафика они приближаются к терабиту. Весь наш трафик поступает к магистральным провайдерам через него.

А что с 7-м уровнем? В случае с хостингом — на 7-м уровне предполагается использование протоколов TLS и HTTPS. Они нужны для защиты передаваемых данных с повышенными требованиями к безопасности.

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

Второй причиной является то, что мы как хостинг-провайдер работаем с очень разнообразными сайтами: на разных фреймворках, с разными правилами маршрутизации, разными куками и т.п… У кого-то на сайте много видео, у кого-то одни картинки, кто-то публикует новости. У кого-то частота запросов большая, у кого-то — маленькая. И так далее. Именно поэтому без понимания нашей специфики неизбежно возникает множество ложно-положительных срабатываний защиты: настроить ее универсально просто невозможно. А объяснять пользователям “Ну вы поймите: мы вас защищали, хотели как лучше, но вот система посчитала ваш трафик невалидным. Простите”, — это не наш метод (хотя и такие кейсы бывают, чего уж там).

Ну и третьей причиной является то, что какая бы хорошая защита не была — она не бывает идеальна. А по-настоящему эффективные средства защиты являются многоуровневыми, работающими в несколько “эшелонов”, каждый из которых работает на своем уровне: от каналов связи, до конечного веб-сервера.

Именно поэтому передать полностью защиту специализированным компаниям будет недостаточно. Не получится “просто заплатить и расслабиться” ????

Как отбиваются атаки
Давайте рассмотрим несколько типов атак и разберем, какие части на нашей схеме в первую очередь станут “бутылочным горлышком”.

UDP/TCP Flood
Это один из наиболее частых видов атак, которые мы отбиваем. Он представляет из себя большой объем трафика, который летит в нашу сторону. Смысл атаки — создать такой объем трафика на входе сети, который, по задумке атакующего, нельзя обработать без отбрасывания валидных пакетов.

Таким образом, на схеме мы можем заметить несколько уязвимых мест:

• Каналы связи с операторами (2).
• Пограничный маршрутизатор (3)
• Операторы связи (1) (сюрприз!)

На графиках с трафиком на границе сети такая атака как правило имеет характерный вид:



В зависимости от силы атаки у нас есть несколько вариантов действий:

А. Забить и ничего не делать
Самый простой вариант. Подходит, когда атака слабая и у нас есть большой запас по каналам связи как снаружи сети, так и внутри сети. В этом случае просто смотрим на самый “узкий” канал связи (как правило, это канал до конечного сервера хостинга(5)) и, если укладываемся в него с кратным запасом, то просто следим и ничего не делаем.

Б. Порезать трафик на пограничном маршрутизаторе
Главный критерий для применения такого способа защиты — остался запас емкости в каналах до операторов связи (2). В противном случае сразу переходим к пункту “В”. Данный вариант чуть посложнее, т.к. тут уже требуется анализ поступающего трафика. Обычно есть смысл обращать внимание на следующие параметры:

• src/dst IP
• dst порт
• протокол
• длина пакета
• тело пакета

Для анализа трафика просто отливаем информацию о нем с маршрутизатора при помощи netflow/ipfix или настраиваем port mirroring на сервер с толстым каналом и анализируем трафик вместе с телом пакета на нем.



Чем более “однородный” вредоносный трафик, тем проще его заблокировать без последствий. Часто прилетают атаки на заранее закрытые порты или с 5-10 IP-адресов, или с очень большим размером пакета. Поэтому увидеть закономерность и настроить фильтрацию достаточно просто.

Само-собой, делать это вручную не очень удобно. Поэтому тут подойдут различные системы анализа и визуализации трафика, чтобы было проще и быстрее выявить закономерности. В самом простом случае это связка Prometheus + Grafana с парой дашбордов. Для лучшей аналитики можно использовать что-то вроде Fastnetmon или самописные решения. В идеале нужно добиться того, чтобы правила для блокировки трафика на маршрутизаторе по ряду критериев добавлялись автоматически.

Также не забывайте, что на пограничном маршрутизаторе по умолчанию должны быть закрыты все протоколы и порты, которые не используются для легитимного трафика. Это автоматически отобьет 90% мелких атак =) Например, на виртуальном хостинге у нас практически не используется UDP. Это очень помогает: для всех сетей хостинга можно поставить очень жесткий лимит на объем такого трафика.

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

FlowSpec имеет свои ограничения:

• Не все операторы связи поддерживают эту технологию. А те, кто поддерживает, как правило берут за неё дополнительную плату.
• Набор правил, которые можно передать, обычно ограничен, и в случае очень сложной распределенной атаки, в которой нельзя выделить явные паттерны, заблокировать весь вредоносный трафик не получится.

В любом случае всегда полезно иметь несколько аплинков с FullView (то есть полной связностью со всеми сетями в интернете), и FlowSpec, которые покрывают весь объем легитимного трафика. В этом случае можно просто отключиться от остальных и передать правила для блокировки нежелательного трафика через них.

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

Г. Blackhole
Наверное, это самый печальный вариант отбития атаки, потому что, по сути, мы просто жертвуем атакуемым ресурсом ради того, чтобы остальные ресурсы продолжили работу. Метод равносилен признанию победы атакующего и единственная его цель — минимизация ущерба для остальных клиентов. Осуществляется через специальное BGP Community у операторов связи. Метод не подходит в случае атаки на множество адресов (например, когда пытаются положить сразу весь хостинг).

К счастью, прибегать к этому методу приходится очень редко.

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

Суть атаки заключается в флуде HTTP(S)-запросами к сайту/на ip-адрес пользователя с целью:

• Превысить лимиты хостинга на количество одновременных запросов/процессорное время с целью спровоцировать отключение сайта. По факту мы видим либо большой объем запросов к сайту, либо запросы к “тяжелым страницам” сайта, генерация которых требует много процессорного времени.
• Использовать уязвимости в CMS/фреймворках, чтобы выполнить какой-либо произвольный код. Чаще всего так запускают различные майнеры или флудеры (тут у нас появляется интересная тема про исходящие ddos-атаки, о которой мы можем рассказать отдельно).

Методы борьбы с такими атаками достаточно разнообразные:
А. Блокировка подозрительных запросов по-умолчанию
Любой хороший системный администратор знает, что доступ к ресурсам необходимо предоставлять только тем клиентам, которые ожидаются. В пределе это называется “политикой белого списка”: все, что явно не разрешено, — запрещено. Для веб-серверов массового хостинга это чрезмерно жесткая мера, но и свои “списки” у нас тоже есть.

Так, например, мы по умолчанию блокируем запросы от уникальных User-Agent, которые были замечены в массовом флуде, блокируем ряд ботов и сканеров, которые ведут себя неадекватно: не считают нужным смотреть robots.txt, ходят по сайтам в несколько потоков и прочими способами увеличивают нагрузку на сервер, не принося никакой пользы. Таких ботов в интернете довольно много и список постоянно расширяется.

Также иногда на длительное время блокируются целые подсети, с которых практически нет легитимного трафика, но зато есть массовые автоматические запросы: привет друзьям из поднебесной и сопредельных стран!

Как ни странно, без этих мер, количество паразитных запросов к серверам было бы просто огромным. Зачастую различные сканеры работают по принципу: если сервер что-то вменяемое ответил, то начинаем активно его исследовать; иначе — просто забиваем на него на некоторое время и прекращаем запросы. Поэтому, по нашей практике, если вы начали отвечать на мусорные запросы — дальнейший их поток будет только возрастать.

Б. Слежение за процессами пользователей (MCPU)
Зачастую проблемы на сервере может создать не миллион http-запросов к одному сайту, а всего пару десятков, но очень “точных”. К таким запросам относятся различные уязвимые страницы на сайте, скрипты (как правило, в админках/плагинах), которых при определенных входных данных начинают “творить дичь”: уходить в бесконечные циклы с запросами к БД, генерацию превьюшек из полноразмерных картинок товаров, сбросу кеша. В конце концов, есть множество уязвимостей, результатом эксплуатации которых будет майнер крипты, работающий от вашего имени на хостинге (и, к сожалению, майнить он будет не в ваш кошелек).

В итоге сервер загибается под бесполезной нагрузкой.

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

Мы пошли по пути активного мониторинга процессов на сервере. У нас есть свой демон на Rust, который постоянно следит за всеми процессами пользователей и имеет постоянно пополняющийся набор правил для выставления ограничений (вплоть до убийства), для тех процессов, которые мы считаем неуместными. Он умеет смотреть на:

• Различные атрибуты процесса (uid, gid, cmdline, cgroup и т.п.).
• Объем потребляемой памяти.
• Затраченное процессорное время.
• Содержимое исполняемого файла.

В случае совпадения, в зависимости от конкретной задачи, он может выполнять различные действия:

• Логирует событие (для дальнейшего анализа).
• Убивает процесс.
• Помещает в cgroup с заданными параметрами.
• Настраивает OOM Killer для этого процесса.
• … любое другое действие, которое нам потребуется.

Вот кусочек такого конфига:

# kill all binaries with miner cmdline patterns
- match:
    - proc.group: newcustomers
    - proc.exe: ^/home/\w/\w+/
    - proc.cmdline: zcash\.flypool\.org
  action:
    - log
    - kill
    - last

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

- match:  
    - proc.group: newcustomers
    - proc.command: convert
  action:
    - log
    - adjust_oom: 1000
    - cgroup:
            name: convert
            memory:
            memory.limit_in_bytes: 40543505612 # лимит памяти по умолчанию для других процессов меньше
            memory.move_charge_at_immigrate: 0
            blkio:
            blkio.weight: 100
    - last

Помимо прочего этот демон выставляет нужные нам cgroup для ряда служебных процессов в случае их появления.

В. Анализ и слежение за запросами к сайтам в реальном времени
Безусловно, выявить зловредные запросы только по атрибутам вроде User-Agent или характерного URL невозможно: часто флудят вполне валидными на вид запросами к разным страницам с разными адресами.

Чтобы работать с такими атаками можно использовать несколько уровней защиты:

На сервере (5)
Полезно будет анализировать лог входящих запросов, искать подозрительные паттерны, характерные тайминги и автоматически выставлять ограничения/rate-limit для тех src ip, user-agent, которые кажутся нам подозрительными. Подойдет против простых атак, которые может переварить сервер без ущерба для остальных. Но на самом деле простых атак —большинство и именно на этом уровне выполняется большая часть блокировок.

Внутри сети (4)
Если сервер не справляется, то уместно будет проксировать трафик к сайту/серверу через специальные серверы, которые могут переварить множество tls-хендшейков и отделить невалидные запросы от валидных, и выполнить еще какую-либо дополнительную фильтрацию. На сервер при этом прилетает уже только валидный HTTP-трафик. Подойдет, если флуд состоит из множества невалидных https-запросов и атака нацелена на перегрузку CPU.

В качестве заключения
Увы, нет какого-то единственно верного способа защитить всех, навсегда и от всего.

Нельзя ни делегировать защиту на подрядчика (по крайней мере полностью), ни настроить 1 раз правила фильтрации.

Более того, под DDoS порой попадают даже самые безобидные сайты, а общий объём атак поистине огромен и в последние месяцы их интенсивность только возрастает.

По сути, ключевой способ защиты для любого хостинга — это накопленная экспертиза админов, которые систематизируют и внедряют защиту: где-то с помощью внешних решений, где-то с помощью “креатива и творчества” — например, иногда полезно вместо закрытия соединения отправить в ответ пару килобайт мусора, чтобы атакующая вас взломанная веб-камера надолго уходила в раздумья перед тем, как отправить следующий запрос =)

Благодаря всему этому пользователи хостинга чувствуют последствия атак лишь изредка.

Да пребудет с нами аптайм!
beget.com/ru

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

Знаем по себе, ловить дзен гораздо приятнее с Райзен… ну или с Интел — тут кто что больше любит. Мы же на всякий случай приготовили скидки и для тех, и для других:

• 20% на гибкие конфигурации с одним процессором Intel Xeon E5-2620v4
• 25% на гибкие конфигурации с двумя процессорами Intel Xeon 2xE5-2620v4
• 50% на гибкие конфигурации с AMD Ryzen 9 5950X и 3900X

Скидка будет действовать на любой выбранный период оплаты: 1, 3, 6 или 12 месяцев.
Сроки проведения акции — с 18 по 31 октября 2022 года.
https://firstdedic.ru

• Ryzen 9 5950x 16 ядер 32 потока / 32 ddr4 HyperX FURY 3200 МГц / 2x 1 ТБ NVME Kingston / 100 mbps — 7000р/мес
• Ryzen 9 5950x 16 ядер 32 потока / 64 ddr4 HyperX FURY 3200 МГц / 2x 1 ТБ NVME Kingston / 100 mbps — 9000р/мес
• Ryzen 9 5950x 16 ядер 32 потока / 128 ddr4 HyperX FURY 3200 МГц / 2x 1 ТБ NVME Kingston / 100 mbps — 11000р/мес

+64 ГБ usb flash бесплатно
+480 SSD/NVME через usb +1000р/мес
+2 ТБ HDD usb +1000р/мес

Покупка в собственность, далее 2500р/мес
100000р/разово (любые методы оплаты)

Чтобы заказать — нужно создать тикет
bill.yacolo.net

Это рассылка свежих новостей от облачной платформы immers.cloud.

Мы рады сообщить о запуске виртуальных серверов с графическими ускорителями NVIDIA Tesla A100 80 ГБ.

Перейдите на совершенно новый уровень производительности — используйте NVIDIA Tesla A100 на базе новой архитектуры Ampere.
Каждый ускоритель имеет 432 тензор-ядер (до 624 ТФЛОПС), 6912 CUDA-ядер и 80 ГБ памяти HBM2 с пропускной способностью до 2 ТБ/с.

Новые конфигурации уже доступны в разделах Облачные серверы с Tesla A100 и Конфигурации.

Подписывайтесь на наш Телеграм-канал для получения информации о специальных предложениях и обновлениях: t.me/immers_cloud.

Желаем успехов, команда immers.cloud
Поддержка:
Telegram @immerscloudsupport
Email support@immers.cloud
https://immers.cloud