Рейтинг
0.00

FirstVDS Хостинг

14 читателей, 546 топиков

DDoS-атаки 2026: эволюция угрозы. Кто находится в зоне риска?




Раньше считалось, что DDoS-атаки направлены на «крупную рыбу» — корпорации, госкомпании, банки. Но реальность 2026 года говорит о другом: жертвой злоумышленников может стать кто угодно.

За три года число атак выросло с 2,2 до 2,5 млн. Их распределённость увеличилась на 480%. DDoS-атаки стали массовым, доступным и, что самое опасное, «автоматизированным» инструментом.

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

Вместе с DDoS-Guard мы решили разобраться, а есть ли кто-то, кто оказывается в красной зоне риска чаще других? Изменился ли характер атак за последние несколько лет? Для этого мы проанализировали данные клиентов, глобальную статистику атак и опросы владельцев бизнеса. В итоге получили портрет «идеальной» жертвы.

Как мы проводили исследование
Чтобы картина получилась объективной, каждая из компаний изучала данные со своей стороны, а затем мы объединили результаты.

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

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

Со своей стороны специалисты из DDoS-Guard предоставили глобальную статистику атак за три года — более 7,5 млн инцидентов. Эти данные охватывают типы атак, отраслевую структуру, географию источников и сезонные колебания.

Затем мы объединили все данные в единое исследование. Временной охват: 2023–2025 годы с экстраполяцией на 2026-й.

Анатомия DDoS-атаки
Для начала разберёмся, что из себя представляет современная DDoS-атака. Тем более, что за последние три года она серьёзно эволюционировала.

Кого атакуют
В 2023 году лидерами по числу атак были сферы «Искусство и досуг» (21%) и «Интернет и телеком» (15,6%), а также «СМИ» (12%).

К 2025 году картина изменилась. Теперь в лидеры вырвались сферы «Интернет и телеком» (24,5%), «Финансы» (15,5%) и «Государство и законодательство» (15%).


Также глобальная статистика DDoS-Guard помогла сделать другие интересные выводы. Количество атак на игровые сервисы в 2025 году выросло на 310% по сравнению с 2024 годом. Цифра, которая заставляет задуматься. Почему гейминг? Наше предположение: игроки вовлечены эмоционально, и даже короткий даунтайм для них катастрофа. Если вы пользуетесь Steam, то наверняка помните октябрь 2025, когда платформа лежала из-за DDoS-атаки. Час простоя — и компания потеряла часть аудитории и понесла огромные убытки.

Прирост атак по отраслям, 2023–2025 гг. (статистика DDoS-Guard)



Также растут атаки на государственные порталы (+249,6%), интернет и телеком (+80,8%) и финансовые сервисы (+45,4%). Здесь причины, вероятнее всего, завязаны в большей степени на политику и экономику.

Что касается бизнес-сектора, картина тоже получается интересная. В 2024 году атаки на бизнес-сектор выросли почти на 63%, а в 2025 — снизились на 2,6%. Правда, радоваться рано, угроза никуда не делась. Да, хакеры сосредоточились на других целях, но и про бизнес не забывают.

Таким образом, статистика DDoS-Guard показывает: в 2025 году внимание хакеров сосредоточилось на телекоме, финансах и госсекторе — это лидеры по количеству атак среди отраслей. Если говорить о динамике, то хакеры стали чаще бить по игровой индустрии и здравоохранению. Бизнес-сектор тоже в списке — даже при небольшом спаде в 2025 году риск для него остаётся высоким.

Согласно данным нашего опроса, почти две трети клиентов (63,85%) сообщили, что их проекты сталкивались с атаками за последний год. А среди пострадавших чаще всего встречались представители IT-услуг и SaaS (37,5%), e-commerce (25%) и игровой индустрии (18,3%).


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

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

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

Любопытно, что в 2023–2025 годах пик подключений защиты приходился на март-апрель. В 2026-м такого не случилось. Почему — только гадаем. Может, весной традиционно запускают новые проекты. А может, просто совпадение. Ясно одно: сезонных передышек не будет.

Гораздо интереснее оказалось проверить связь с «возрастом» проекта. 40% атак приходятся на первые два месяца после запуска сервера. И это логично: ботнеты круглосуточно сканируют интернет в поисках свежих IP-адресов и доменов. Новый сервер автоматически становится целью.

Впрочем, наши данные говорят, что большинство клиентов подключают защиту превентивно: 57% — сразу при покупке сервера, ещё 16% — в течение первых двух месяцев. Судя по опросу, многие из них уже сталкивались с атаками раньше и действуют на опережение.


Вывод: получается, первые два месяца после запуска сервера — время, когда риск атаки максимален. И никаких «тихих» месяцев нет: атаки идут круглый год.

Атаки стали длиннее и умнее
Теперь о том, как именно выглядит современная DDoS-атака. Данные опроса и глобальной статистики рисуют тревожную картину.

Начнём с периодичности. Почти треть пострадавших за год пережили атаки 1–3 раза. Но столько же (32,56%) сталкиваются с ними регулярно, раз в месяц или чаще. А 11,63% живут под постоянным давлением — ежедневно или ежечасно. Для многих это не разовое событие, а хроническая проблема.



Раньше считалось, что DDoS — это краткосрочный удар, чтобы досадить или вынудить заплатить. Но сегодня ситуация складывается иная. Согласно опросу, 31,62% атак длятся более суток, ещё 21,37% — от 1 до 6 часов. И только 15,38% укладываются в промежуток 10–60 минут, который раньше считался «золотой серединой».



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

Меняется не только длительность, но и сама природа атак. Глобальная статистика DDoS-Guard за три года показывает устойчивое смещение в сторону прикладного уровня.



Общее число атак растёт — с 2,26 млн в 2023 до 2,5 млн в 2025. Но важно другое: L7-атаки растут и в абсолютных цифрах, и в доле (с 80,4% до 83,7%), а L3/L4-атаки, наоборот, снижаются.

Хакеры всё чаще бьют на прикладном уровне — имитируют поведение реальных пользователей, грузят тяжёлые страницы, дёргают API, перегружают базу данных и процессор. Канал при этом может оставаться свободным, а сервер — задыхаться. Такую атаку сложнее заметить и отразить.



И ещё один опасный паттерн, который набирает популярность, — Pulse Wave. Это когда волны вредоносного трафика идут с короткими паузами. Многие системы защиты «успокаиваются» во время паузы, а затем не успевают среагировать на новую волну. Это сбивает с толку автоматику и делает защиту бесполезной.

DDoS-Guard проанализировала более 10 000 атак на крупной точке обмена трафиком — и 27% из них оказались Pulse Wave. Тактика, которая ещё несколько лет назад считалась редкой и сложной, сегодня становится мейнстримом.

География атак
Картина источников атак каждый год примерно одинаковая, но с локальными ротациями.

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

Следующие места чаще всего занимают страны Латинской Америки (например, Бразилия) и Юго-Восточной Азии (Индонезия). Причина? Огромное количество IoT-устройств с заводскими паролями, которые становятся частью ботнетов.

Также в топе — Китай (особенно Гонконг) и Германия. У первых — бесконечное количество уязвимых устройств, у вторых — высокая плотность телеком-инфраструктуры.



В 2026 году к этому списку добавился Бангладеш — регион с низким уровнем цифровой грамотности и массовым распространением «умных устройств».

За два года распределённость атак выросла на 480%. В 2023 году количество уникальных IP-адресов, задействованных в одной атаке, составило 353 тысячи. В 2025 — уже более 2 миллионов, а в первом квартале 2026 года произошла атака, в рамках которой были зафиксированы уже 3,1 млн уникальных IP-адресов.

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

Вывод: современные атаки распределённые, и профессиональная фильтрация трафика — основной инструмент защиты. Одной геоблокировки будет недостаточно.

Паттерн современной атаки: краткий вывод
Если обобщить всё, что мы узнали о современных DDoS-атаках, получается следующая картина.

С вероятностью 80% это будет атака на прикладном уровне L7. Скорее всего, она будет распределённой — трафик придёт одновременно из тысяч источников по всему миру. Длиться она может часами, а в каждом третьем случае — сутками и более. При этом атака, скорее всего, будет использовать тактику Pulse Wave: волны трафика с паузами, чтобы сбить с толку автоматические системы защиты.

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



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

Как узнают об атаке
Для 40% опрошенных сигналом стала полная недоступность сайта или сервиса. То есть они узнают о проблеме постфактум — когда она уже случилась. Ещё 23% полагаются на системы мониторинга, которые срабатывают в момент атаки. Остальные замечают аномалии в логах, получают уведомления от хостинг-провайдера или получают информацию от пользователей.


Какие решения используют для защиты
Мы также посмотрели, какие решения использовали наши клиенты до текущего момента. 37,29% респондентов обращались к сторонним сервисам (например, Cloudflare), 33,33% настраивали защиту самостоятельно — фаерволы, скрипты. 25,42% не использовали ничего.

Среди клиентов FirstVDS, которые подключают защиту, часть использует решение от DDoS-Guard. Оно встроено в нашу хостинг-инфраструктуру и доступно как отдельная услуга.

Последствия и восприятие риска
Один из наших вопросов звучал так: к каким последствиям приводили атаки. Почти половина опрошенных (48,62%) пережили полные простои и недоступность сервиса. Для 19,27% атака привела к деградации работоспособности — сайт работал, но с перебоями. 13,76% респондентов сказали, что «не было значительных последствий».


При этом бизнес чувствует ухудшение ситуации: 44,6% опрошенных считают, что риск DDoS-атак для их отрасли вырос по сравнению с прошлым годом. И только 6,2% видят снижение риска.

Интересное. В 2025 году количество обращений в поддержку с упоминанием DDoS сократились на 38%. Прямой связи с подключением защиты мы не проверяли, но тренд любопытный. Атак больше, а обращений за помощью меньше.

Общий вывод по блоку
Две трети опрошенных сталкивались с атаками за последний год. Почти половина из них пережили простои. При этом среди респондентов оказалось много тех, у кого защиты нет, а те, кто её подключает, используют разные решения — от бесплатных сервисов до профессиональных. И многие считают, что риск только растёт.

Кто под прицелом и что делатьТеперь у нас есть достаточно данных, чтобы собрать портрет «идеальной» жертвы.

В зоне повышенного риска — владельцы игровых сервисов, SaaS-платформ, интернет-магазинов, госсектор, телеком и финансовые проекты. Именно эти сферы хакеры атакуют активнее всего, по данным глобальной статистики и опроса.

Риск атаки особенно высок в первые два месяца после запуска проекта — на этот период приходится 40% всех случаев. Вероятнее всего, это будет L7-атака — на прикладном уровне, с имитацией поведения реальных пользователей. И продлится она более суток в каждом третьем случае. Трафик может прийти одновременно из миллионов источников по всему миру и идти волнами.

Что делать, чтобы не стать частью этой статистики:
  • Установить защиту в день запуска сервера. 40% атак случаются в первые два месяца. Ждать некогда.
  • Выбрать решение, которое соответствует современным угрозам. Атаки сместились на прикладной уровень, и инструменты, которые работали раньше, могут не справляться с распределённым L7-трафиком.
  • Настроить мониторинг. Не ждите, пока сайт упадет. Система должна предупреждать об аномалиях до того, как сервис станет недоступен.
  • Не полагаться только на геоблокировку. Она может быть полезна для локального бизнеса, но против глобальных распределённых атак нужна фильтрация трафика на уровне поведения, а не только по географическому признаку.

Атаки становятся умнее, длиннее и распределённее. Они происходят круглый год, без сезонных пауз. Данные исследования подтверждают: даже если одни цели привлекают хакеров больше других, под ударом может оказаться любой проект — независимо от размера и сферы.

Исследование подготовлено на основе совместных данных DDoS-Guard и FirstVDS. В анализе использованы внутренняя статистика FirstVDS, глобальная статистика DDoS-Guard за 2023–2025 годы (более 7,5 млн атак) и результаты опроса 204 владельцев бизнеса, проведённого FirstVDS.

firstvds.ru
ddos-guard.net

Июль — переезд в новый ЦОД, новые рецепты, обзор первого закона об ИИ и туториалы по безопасности на Хабре

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



Если вы тоже из тех, кто проводит июль в офисе, давайте держаться вместе. Собрали для вас дайджест с полезными туториалами и актуальными новостями. Разберёмся с рабочими задачами, а там ещё останется куча времени для летних приключений!

Статьи и инструкции
Что такое NVMe SSD и чем он отличается от SATA SSD

При выборе сервера или VDS многие наверняка сталкивались с терминами SATA, SSD, NVMe и M.2. В статье разбираем, что означают эти понятия, сравниваем параметры и сценарии использования и помогаем выбрать накопители под свои задачи.
firstvds.ru/blog/chto-takoe-nvme

Первый закон об ИИ в России: что изменится для разработчиков и пользователей
До недавнего времени в законах не было даже определения ИИ. Теперь этот пробел закрыт: в марте 2026 года Минцифры предложило первый законопроект. Однако после активных обсуждений приняли решение его доработать. В статье разбираем основные тезисы обоих документов и кого коснутся изменения.
firstvds.ru/blog/pervyy-zakon-ob-ii-v-rossii-chto-izmenitsya-dlya-razrabotchikov-i-polzovateley

Как сменить данные администратора домена
С 1 сентября 2026 года в России будет введена обязательная идентификация администраторов доменов в зонах .ru,.рф и .su через портал госуслуг (ЕСИА). Без идентификации управлять доменом, в том числе продлить его, не получится. В статье расскажем, как проверить данные администратора и актуализировать их.
firstvds.ru/technology/kak-izmenit-dannye-administratora-domena-v-zonakh-rusurf

Habr: самое интересное за июль
На Хабре в этот раз сложно, но интересно. Хит месяца — статья о работе модуля LoRa. Загляните в комментарии, там настоящая битва умов: инженеры спорят о физике, кодировании и том, как выжать из LoRa максимум.

Также подготовили три полезных туториала. Расскажем, как строить локальную RAG-систему на базе понятного и полностью локального стека: Go + PostgreSQL + Ollama. А также представим подробное руководство по расследованию инцидентов в Linux в двух частях.


Ищем авторов для блога на Хабр.
Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, вы получите повышенный гонорар. Тема августа: DIY или Сделай Сам.
firstvds.ru/avtoram

Новости июля
Меняем ЦОД в Нидерландах

Приняли решение о переезде, поскольку охлаждение в Qupra DC2 всё ещё работает на резервном чиллере без дополнительного питания. Ждать полного восстановления площадки небезопасно для наших клиентов.
Мы сравнили доступные дата-центры в Нидерландах и выбрали NorthC Amsterdam 1 — как самый оптимальный баланс надёжности и скорости миграции. Новая площадка соответствует стандарту Tier III, имеет прямое подключение к AMS-IX (одной из крупнейших точек обмена трафиком в мире).
Переезд спланирован так, чтобы полностью исключить время недоступности серверов или свести его к минимуму — работы будут проходить в ночное время и выходные. Полный переезд займёт 1–1,5 месяца, точный график опубликуем позже и отправим уведомления на почту.
firstvds.ru/blog/pereezzhaem-v-northc-amsterdam-1


Добавили новые рецепты для автоустановки на сервере
Добавили два новых бесплатных рецепта для быстрого развёртывания сервисов на VDS — без ручной настройки.
Open WebUI + Ollama — готовое решение для работы с LLM на своём сервере. Позволяет общаться с LLM через веб-чат, загружать модели, управлять пользователями и правами доступа, подключать внешние API и хранить истории диалогов. Все данные остаются внутри вашей инфраструктуры — запросы не уходят в облачные сервисы.
firstvds.ru/technology/nachalo-raboty-s-open-webui-i-ollama
WordPress — автоматическая установка популярной CMS с готовым окружением: Apache, PHP-FPM, MariaDB, HTTPS и firewall. Подойдёт для запуска блога, корпоративного сайта, лендинга или витрины.
firstvds.ru/technology/nachalo-raboty-s-wordpress


Хорошие новости из Казахстана
В алматинской локации подключили ТТК в качестве второго аплинка наряду с провайдером RETN. Сейчас трафик между ними распределяется равномерно: в случае сбоя у одного из провайдеров сервисы останутся доступными.


Акция «Кешбэк по выходным» подходит к концу
У нас для вас две новости — срочная и приятная.
Срочная: акцию с кешбэком по выходным завершаем досрочно — уже 2 августа. Это значит, что ближайшие выходные (31.07–2.08) — последний шанс пополнить баланс с выгодой до 10%.
firstvds.ru/actions/cashback_weekend

Карты, деньги, два кешбэка



Лето — это когда хочется ничего не делать, но чтобы всё работало само.

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

Каждые пятницу, субботу и воскресенье до 30 августа за пополнение баланса на рекомендуемую сумму и выше можно получить кешбэк до 10%. Посмотреть рекомендуемую сумму можно через форму пополнения баланса на сайте или в Личном кабинете.

Процент кешбэка различается в зависимости от метода оплаты и дня недели:



firstvds.ru/actions/cashback_weekend

Повышение цен на реселлерские тарифы



С 1 августа 2026 года стоимость реселлерских тарифов увеличится в среднем на 16%. Изменение коснётся как действующих, так и архивных тарифов:
  • VDS-KVM-Реселлинг-5.0
  • VDS-KVM-SSD-Реселлинг-5.0
  • VDS-KVM-NVMe-Реселлинг-5.0
  • VDS-KVM-Реселлинг-6.0
  • VDS-KVM-SSD-Реселлинг-6.0
  • VDS-KVM-NVMe-Реселлинг-6.0
  • VDS-KVM-Реселлинг-7.0
  • VDS-KVM-SSD-Реселлинг-7.0
  • VDS-KVM-NVMe-Реселлинг-7.0
  • VDS-KVM-Реселлинг-8.0
  • VDS-KVM-NVMe-Реселлинг-8.0
  • VDS-KVM-SSD-Реселлинг-8.0
  • VDS-KVM-SSD-Реселлинг-9.0
  • VDS-KVM-NVMe-Реселлинг-9.0
  • VDS-KVM-SSD-Реселлинг-10.0
  • VDS-KVM-NVMe-Реселлинг-10.0
  • VDS-KVM-SSD-Реселлинг-2015
  • VDS-KVM-Реселлинг-2015

Цена услуги будет зависеть от конфигурации тарифа. Итоговую стоимость можно узнать в Личном кабинете в день повышения цен — 1 августа 2026 года.

Локация «Амстердам»: переезжаем в новый дата-центр NorthC Amsterdam 1



Выполняем обещание и переносим инфраструктуру на новую площадку. Рассказываем о партнёре и плане миграции.

3 июля мы опубликовали подробный разбор инцидентов в локации «Амстердам» и сообщили о решении найти для наших серверов новую площадку. Мы понимаем, насколько важна стабильность ваших проектов, поэтому сегодня готовы объявить: мы переезжаем в дата-центр NorthC Amsterdam 1.

Почему мы уходим из Qupra DC2 и почему именно сейчас
Охлаждение в Qupra DC2 всё ещё работает на резервном чиллере без резервного питания. Ждать полного восстановления площадки небезопасно для ваших проектов — переезжать нужно срочно.

Найти дата-центр уровня Tier 3 со свободными мощностями и возможностью экстренного переезда было сложно. Мы сравнили доступные варианты в Нидерландах и выбрали NorthC Amsterdam 1 как самый оптимальный баланс надёжности и скорости миграции.

Наш новый дом: NorthC Amsterdam 1
NorthC Amsterdam 1 полностью отвечает заявленным нами требованиям к новой площадке.

Что это значит для вас
  • Надёжность уровня Tier 3. Соответствие этому стандарту означает резервирование ключевых инженерных систем: электропитания, охлаждения и сетевых подключений. Все системы имеют резерв, который включается автоматически в случае сбоя.
  • Прямое подключение к AMS-IX. NorthC является точкой присутствия (PoP) Amsterdam Internet Exchange — одной из крупнейших точек обмена трафиком в мире. Это обеспечит серверам отличную связность и минимальные задержки.
  • Современная инфраструктура. Площадка отвечает высоким стандартам эксплуатации и принадлежит NorthC — крупному оператору, который управляет сетью дата-центров в Нидерландах, Германии и Швейцарии.
В условиях, когда нам необходимо срочно покинуть текущую локацию, именно этот дата-центр предложил лучший баланс между техническими возможностями и скоростью организации переезда.

План переезда: что будет дальше
Мы уже начали подготовку к миграции. Полный переезд локации займет 1–1,5 месяцев. Точные даты и детальный график работ мы анонсируем отдельной новостью, как только план будет окончательно согласован. Мы постараемся сделать переезд максимально бесшовным.

Уже сейчас можем подтвердить ключевые принципы, по которым будет проходить миграция:
  • Минимальный простой: Мы спланируем работы так, чтобы исключить время недоступности ваших сервисов или свести его к минимуму. Перенос будет проходить в ночное время и в выходные дни.
  • Сохранение IP-адресов: Как и обещали, все ваши текущие IP-адреса будут сохранены. Вам не придётся вносить изменения в настройки DNS или конфигурацию своих проектов.
  • Персональные уведомления: Каждый клиент, чьи услуги затронуты, заранее получит отдельное письмо на электронную почту и уведомление в личном кабинете со временем проведения работ по его серверу.
Спасибо за ваше терпение и понимание. Следите за нашими новостями и почтовыми рассылками.

Добро пожаловать в семью!



При выборе провайдера важно, чтобы всё работало стабильно, настраивалось под ваши задачи и не превращалось в бесконечную головную боль.

FirstVDS уже 23 года помогает запускать и развивать проекты любого масштаба — от небольших сайтов и ботов до крупных сервисов и рабочих сред для разработки.

У нас надёжная инфраструктура, дата-центры в России, Нидерландах и Казахстане, гибкие тарифы и живая поддержка 24/7.
Если вы только выбираете сервер

У нас можно начать с простого и недорогого решения или сразу собрать конфигурацию под свои задачи.

Что вы получаете:
  • серверы от 299 ₽/мес.,
  • многообразие готовых тарифов и возможность гибкой настройки ресурсов,
  • круглосуточную поддержку без ботов,
  • обширную базу знаний.

firstvds.ru/products/vds_vps_hosting

А если настала пора сменить провайдера
Переезд — это не обязательно долго, сложно и больно.
Мы поможем перенести ваши проекты на FirstVDS и дадим ещё более выгодные условия на старте.

Вы можете выбрать один из бонусов:
  • 3 месяца в подарок при оплате сервера на год,
  • или скидку 40% на первый месяц при оплате на любой срок.

А ещё вы получите:
  • бесплатный перенос до 10-ти проектов,
  • помощь с настройкой сервера под ваши задачи,
  • поддержку 24/7,
  • до 3-х дней тестового периода.

Инцидент с охлаждением в дата-центре локации «Амстердам» (Qupra DC2). Постмортем и наши обязательства



Статус на момент публикации (3.07.2026). Все серверы локации «Амстердам» работают в штатном режиме. Дата-центр функционирует на внешнем (резервном) чиллере; работы по восстановлению основной системы охлаждения продолжаются. Мы держим ситуацию под усиленным контролем. Пока основная система охлаждения не восстановлена и не подтверждён резерв, мы считаем ситуацию незакрытой.

Это подробный разбор того, что произошло с локацией «Амстердам» в мае–июле 2026 года, почему это случилось, что мы сделали не так и что делаем дальше. Мы понимаем, что подвели вас, и приносим извинения. Ниже — по существу

Коротко о главном
  • В мае–июле 2026 года в дата-центре нашей локации «Амстердам» (Qupra DC2) произошла серия отказов системы охлаждения. Оборудование уходило в аппаратную защиту от перегрева, из-за чего серверы были недоступны.
  • Первопричина — отказы системы охлаждения на стороне дата-центра. Аномальная жара стала триггером, но не единственной причиной: цепочка инженерных и эксплуатационных отказов на площадке превратила единичный сбой в каскад (подробно — ниже).
  • Данные клиентов сохранены. Аварии касались доступности, а не целостности данных.
  • Компенсация и бонусы для пострадавших клиентов локации «Амстердам»: возврат за фактический простой на баланс (тикет в техподдержку, по SLA) плюс бонусы-промокоды на продление — QUPRA100 (100% на 14 дней) и следом QUPRA15 (15% на 3 месяца). Для уже ушедших клиентов — отдельный порядок. Подробнее — в разделе «Компенсации и бонусы».
  • Мы не рассматриваем гарантии или доработки со стороны Qupra — только переезд локации на новый дата-центр.
  • Повышение цен, о котором вы получили уведомление, — не связано с инцидентом: это совпадение по времени, и мы это учли (см. раздел «О ценах»).

Что произошло
В дата-центре Qupra DC2 (Амстердам), где размещена наша локация «Амстердам», несколько раз выходила из строя система охлаждения. Когда охлаждение останавливается, оборудование в стойках быстро перегревается, и включается защита. Часть её срабатывает автоматически, на уровне железа: процессоры снижают частоты (троттлинг), а при достижении критической температуры сервер аппаратно выключается сам. Часть — управляемо, по нашему решению: чтобы не ронять машины жёстко и сохранить ваши данные, мы штатно и контролируемо выключаем серверы (graceful shutdown), а дата-центр при необходимости обесточивает перегретые стойки со своей стороны. Результат в любом случае один: сервер временно недоступен.

Каждый такой отказ приводил к многочасовому простою локации. Самая длительная авария в конце июня — начале июля растянулась почти на двое суток.

Хронология
Ниже — все известные нам эпизоды недоступности локации «Амстердам», связанные с охлаждением. Время указано по МСК.
  • 27.05.2026, 12:33 → 19:42 (≈5 часов). Отказ системы охлаждения: вышел из строя основной чиллер на крыше. Вечером дата-центр привёз и установил резервный чиллер.
  • 26.06.2026, 16:51 → 21:55 (≈5 часов). Снова отказ охлаждения. Инцидент пришёлся на ночь выходного дня. Мы не опубликовали о нём информацию своевременно — это была ошибка (см. раздел «Что мы сделали неправильно»).
  • 29.06.2026, 13:10 → 16:58 (≈4 часа). Очередной отказ охлаждения.
  • 29.06 (поздний вечер) → 01.07.2026, 22:24 — самая длительная авария (≈44 часа). Отказавший чиллер запустить не удалось. Дата-центр организовал доставку и подключение внешнего чиллера, но подключение затянулось из-за отсутствия на площадке нужных силовых кабелей — их привезли только 1 июля. Внешний чиллер подключили около 14:00, серверы начали подниматься примерно с 15:30, восстановление шло поэтапно.
Суммарная недоступность локации за май–июль составила порядка 58 часов. Мы не считаем это приемлемым и не спорим с вашими собственными подсчётами простоя — они верны.

Почему это произошло
Триггером отказов стала аномальная жара в Западной Европе летом 2026 года: система охлаждения площадки не удержала тепловую нагрузку при высокой наружной температуре. Но жара — не единственная причина. За затяжным простоем конца июня стоит цепочка инженерных и эксплуатационных отказов на самой площадке.

Что именно отказало
Приводим восстановленную картину работы инженерных систем дата-центра — по информации, которой мы располагаем.
  • До конца мая охлаждение обеспечивал основной чиллер на крыше здания. 27 мая он вышел из строя.
  • Дата-центр привёз резервный чиллер, разместил его за зданием и запитал от внешнего дизель-генератора, подключив к системе охлаждения. Нам сообщили, что основной (крышный) чиллер также восстановлен.
  • В конце июня внешний дизель-генератор, питавший резервный чиллер, был убран с площадки — и резервный чиллер обесточился.
  • Дата-центр переключился на основной чиллер, но тот, вопреки сообщению о восстановлении, к вечеру отказал окончательно — запустить его не удалось даже с привлечённым сервисным инженером.
  • Оперативно найти замену дизель-генератору не получилось. Для подключения резервного чиллера напрямую к электрощиту площадки пришлось заказывать силовые кабели (около 60 метров), доставка заняла порядка суток. На это время охлаждение держали на фрикулинге, без компрессора.
  • После доставки кабелей резервный чиллер подключили штатно, и охлаждение вышло на рабочий режим. На сегодня локацию охлаждает один исправный чиллер; второй (на крыше) остаётся в восстановлении.
Мы приводим эту цепочку не чтобы переложить вину, а потому что она объясняет наше решение. Критически важный контур охлаждения держался на временном внешнем дизель-генераторе; чиллер, о восстановлении которого нам сообщили, при первой же нагрузке отказал; на площадке не оказалось ни резервного питания, ни готовых кабелей для быстрого ввода резерва. Повторяющиеся отказы, судя по всему, лишь усугубляли износ оборудования, а адекватной реакции площадки мы не увидели. Единичный сбой каскадом обрушил всю локацию. Это не разовое невезение и не только погода — это состояние инженерной инфраструктуры и эксплуатации площадки.

Наша ответственность
Мы не будем прятаться за формулировкой «виноват дата-центр». За питание и охлаждение физически отвечает площадка, а не хостинг-провайдер, — но выбор площадки это наша ответственность. Мы разместили вашу инфраструктуру в Qupra DC2, мы на ней оставались, и перед вами за результат отвечаем мы. Именно поэтому наше решение — уходить с площадки, а не ждать её доработок (см. «Что мы меняем»).

Мы переехали в Qupra DC2 в конце 2025 года, когда прежняя площадка (euNetworks) закрывалась и просила арендаторов освободить помещение. Новый дата-центр оказался не готов держать нашу нагрузку. Это в том числе наш урок по выбору и аудиту площадки.

О слухах: это НЕ история с изъятием серверов
Этим летом в Амстердаме случилось несколько разных инцидентов у разных операторов, и в сети их смешивают. Уточним прямо: наш инцидент — технический, связан только с охлаждением. Он не имеет отношения к истории с принудительным обесточиванием и изъятием серверов у другого оператора в другом дата-центре, которая обсуждалась в те же недели. Ваши серверы никто не изымал и не опечатывал, доступ к ним не блокировался по чьему-либо требованию.

Что с вашими данными
Данные клиентов локации «Амстердам» сохранены. Аварии касались доступности: серверы уходили в защиту и обесточивались контролируемо именно для того, чтобы сохранить оборудование и данные. Потери данных по причине инцидента с охлаждением не зафиксировано. Если у вас есть основания подозревать проблему с целостностью данных на конкретной услуге — напишите тикет, разберём индивидуально и в приоритете.

Что мы сделали неправильно
Отдельно и без смягчений — о наших собственных ошибках.

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

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

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

Компенсации и бонусы
Разделяем две вещи: компенсацию за фактический простой и бонус сверх неё. Оба доступны клиентам локации «Амстердам», чьи затронутые услуги были активны в период инцидента.

Компенсация за простой (по SLA)
Возврат средств за фактическое время недоступности — на баланс, по SLA. Чтобы её получить, напишите тикет в техподдержку: мы рассчитаем простой по вашей услуге и вернём его стоимость на баланс.

Бонусы (промокоды)
Сверх компенсации — два промокода на продление серверов локации NL (все тарифы). Тикет для них не нужен, они применяются вами самостоятельно в личном кабинете. Действуют только для услуг, заказанных до 1 июля 2026; скидка распространяется и на сам сервер, и на дополнительные услуги.

Промокоды применяются последовательно, именно в таком порядке:
  • QUPRA100 — скидка 100% на 14 дней. Активировать с 3 июля по 3 августа. После активации сервер будет работать две недели бесплатно.
  • QUPRA15 — скидка 15% на 3 месяца. Активировать с 18 июля по 31 августа, после того как отработают 14 дней по QUPRA100.
Важно: сначала QUPRA100, затем QUPRA15. Если активировать 15% раньше, он перебьёт скидку 100%. Все действующие скидки отображаются в личном кабинете в разделе «Скидки». Пошаговая инструкция — здесь.

Если вы уже отказались от услуги из-за инцидента
  • Компенсация — в общем порядке: напишите тикет в техподдержку, мы вернём стоимость простоя на баланс (с последующим выводом на вашу карту или счёт).
  • Бонус — в ручном режиме: напишите тикет в отдел продаж и опишите ситуацию. Мы вручную назначим скидку на новую услугу с аналогичными условиями (100% на 14 дней, далее 15% на 3 месяца).
Стоимость новых услуг не должна превышать стоимость ваших услуг, пострадавших в результате инцидента.

Почему мы не компенсируем упущенную выгоду
Отдельно и честно — о том, что многие ждут, но чего мы сделать не можем.

Мы понимаем, что для многих из вас простой — это не «минус несколько часов аренды», а остановленные заказы, недоступные кассы, сорванные процессы и потерянные клиенты. Это реальный ущерб, и мы его не обесцениваем.

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

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

О ценах
Понимаем, как это выглядит со стороны: сервис падал — а вы получили уведомление о повышении цен. Это совпадение по времени: плановое изменение тарифов готовилось заранее и не связано с инцидентом. Тем не менее момент вышел болезненным, и та же скидка 15% на продление затронутых услуг (см. «Компенсации и бонусы») смягчает для вас это повышение.

Что мы меняем
Площадка. Принято решение уходить из Qupra DC2. Сейчас мы выбираем новый дата-центр. Основной кандидат, которого мы оцениваем, — площадка в Амстердаме уровня Tier 3 с сертификацией управления непрерывностью бизнеса (ISO 22301) и точкой присутствия AMS-IX; параллельно рассматриваем ещё несколько вариантов. Решение принимаем на этой неделе. Конкретную площадку, график переезда и порядок переноса объявим отдельным анонсом. Сам переезд спланируем так, чтобы исключить или свести простой к минимуму и заранее предупредить вас по каждой затронутой услуге. Текущие IP-адреса на услугах будут сохранены.

Текущее состояние. До восстановления основной системы охлаждения и подтверждения резерва локация остаётся под усиленным мониторингом. Сейчас она работает на внешнем чиллере.

Коммуникация. Мы работаем по принципу, который в этом инциденте показал себя как единственно
  • правильный, — говорить честно и по делу:
  • регулярные апдейты по расписанию во время аварии, с указанием времени следующего обновления;
  • дежурный специалист на связи во время инцидента;
  • никакой цензуры в чатах — мы не удаляем критику, не баним пользователей за неудобные вопросы, модераторы следят только за порядком.
Продажи. Внедряем механизм остановки приёма заказов в проблемной локации на время аварии, чтобы ситуация с «оплатил — не развернулся сразу» не повторилась.

Извинения
Мы подвели вас — и техническим сбоем, и тем, как повели себя в его первые часы. Спасибо тем, кто разбирал ситуацию публично и задавал неудобные вопросы: это помогло нам увидеть свои ошибки без прикрас. Доверие возвращается не заявлениями, а делами, и мы намерены его вернуть.

Анализ инцидента с сервером виртуализации FirstVDS Казахстан



Вчера (2 июля) один из серверов виртуализации в ЦОД Алматы перестал отвечать, так как произошёл аппаратный отказ процессора AMD EPYC 9655.

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

Инцидент
Необходимо отметить, что сетевые события, происходившие в тот же период, не были прямой причиной аварии сервера. Ни плановые работы на сети оператора, объявленные до инцидента с сервером, ни внеплановые работы на канале, начавшиеся позднее, не были связаны с аппаратным отказом узла виртуализации. Эти события совпали по времени с восстановительными работами и повлияли на сроки миграции виртуальных машин, но не являлись причиной отказа сервера.

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

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

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

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

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

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

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

Потери клиентских данных не зафиксировано.

Первопричина
Первопричиной инцидента стал аппаратный отказ процессора AMD EPYC 9655.

Неисправность проявлялась только под полноценной эксплуатационной нагрузкой. В rescue-окружении сервер мог загружаться и выполнять базовые операции, поэтому на раннем этапе диагностики однозначно подтвердить отказ процессора не удалось.

После запуска основной операционной системы и появления нагрузки от KVM происходило зависание ОС. Это указывало на нестабильность вычислительной части платформы, а не на простой отказ загрузки или единичную проблему дисковой подсистемы.

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

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

Позднее было установлено, что причина незагрузки на доноре была не в отказе самих накопителей. Проблема заключалась в повреждении загрузочной логики: загрузочный раздел на RAID1-массиве был поврежден, а GRUB2 находился в неработоспособном состоянии.

Инженер полностью восстановил загрузку: заново настроил GRUB2 и вручную создал EFI-записи в NVRAM материнской платы. После этого узел начал загружать основную операционную систему, однако под нагрузкой виртуализации снова воспроизводилось зависание ОС.

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

Дополнительное диагностическое наблюдение
Во время диагностики был выполнен обратный тест: диски от другого сервера были установлены в неисправную платформу.

Операционная система с этих дисков загрузилась и работала без зависаний. На первый взгляд это могло противоречить версии об отказе процессора. Однако позднее причина стала понятна: сервер с этими дисками был фактически пустым и не создавал существенной нагрузки на процессорные ядра. На нем не работали клиентские виртуальные машины и процессы KVM с реальной нагрузкой.

Поэтому в таком режиме деградация процессора не проявлялась.

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

Отдельно рассматривался вариант физического демонтажа неисправного процессора. Однако он также не являлся оптимальным: вместе с процессором сервер потерял бы доступ к части оперативной памяти и части NVMe-накопителей, так как они подключены через соответствующие PCI Express-линии. Это могло дополнительно осложнить восстановление и снизить вероятность корректного доступа ко всей конфигурации узла.

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

Стабилизация узла
После восстановления GRUB2 и EFI-записей сервер начал загружать основную операционную систему, но зависал при появлении нагрузки от виртуализации.

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

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

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

Дополнительный сетевой фактор
После стабилизации узла была начата подготовка к миграции виртуальных машин. При сохранении сетевой связности перенос виртуальных машин должен был занять около 2,5 часов.

Параллельно с восстановительными работами на сервере магистральный оператор RETN начал плановые работы без предварительного уведомления FirstVDS. По информации оператора, причиной отсутствия уведомления стала человеческая ошибка.


После восстановления интернет-связности миграция была продолжена.

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

Потери клиентских данных не произошло.

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

Выводы
Инцидент был вызван нестандартным аппаратным отказом процессора AMD EPYC 9655. Отказ не проявлялся в минимальном rescue-окружении и становился заметен только после запуска полноценной операционной системы под нагрузкой виртуализации.

Диагностику осложнили следующие факторы:
  • Повреждение загрузочного раздела RAID1 и неработоспособность GRUB2.
  • Необходимость вручную восстанавливать GRUB2 и EFI-записи в NVRAM материнской платы.
  • Длительная самодиагностика серверной платформы после каждого зависания и перезагрузки.
  • Неочевидный характер отказа процессора, который проявлялся только под нагрузкой KVM.
  • Независимое сетевое событие, вызванное незаявленными работами оператора RETN.

Какие меры мы уже предприняли и что ещё планируем сделать:
  • Вся хронология событий и симптомы проблемы внесены в нашу внутреннюю базу знаний, чтобы в случае возникновения аналогичной ситуации время на устранение значительно сократилось.
  • В ближайшее время мы закончим организацию второго канала с магистральным провайдером Транстелеком Казахстан, чтобы не зависеть только от RETN.
  • Возместим время простоя вашего VPS в локации Казахстан за 2 июля. Для этого, пожалуйста, напишите запрос в техподдержку.

Июнь — мониторинг сайтов, летний кешбэк и новые правила по работе с SSL

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


Мы решили: хватит тонуть в завалах. Быстренько наводим порядок в делах, закрываем хвосты и позволяем себе расслабиться. Собрали в новом выпуске всё, что для этого нужно. Заходите и забирайте:
  • свежие рецепты для автоустановки ПО, чтобы ускорить старт проектов,
  • важные изменения, которые влияют почти на всех, поэтому лучше быть в курсе,
  • гайды и инструкции — готовые решения разнообразных задач,
  • новые услуги, подборка занимательных статей с Хабра и приятный бонус, чтобы почувствовать прелесть лета даже в офисе.
В общем, листайте и выдыхайте!

Статьи и инструкции
Установка и настройка Portainer

Если у вас несколько Docker-хостов, может возникнуть вопрос, как управлять ими централизованно. Ответ — Portainer, веб-платформа для организации контейнерной инфраструктуры через единый GUI и REST API. Подключается к средам на базе Docker, Docker Swarm и Kubernetes и позволяет администрировать их из одного интерфейса. В статье на примере Ubuntu 24.04 пошагово показываем, как поднять и запустить её вручную
firstvds.ru/technology/ustanovka-i-nastroyka-portainer
Как установить и запустить vLLM: от базовой проверки до тяжёлых моделей
vLLM — сервер для запуска ИИ-моделей с открытым API. С его помощью можно поднять локальный эндпоинт для больших языковых моделей и подключить к нему свои приложения, чат-ботов или агентов. В статье рассказываем про два варианта установки vLLM — uv и Docker, а также разбираем основные параметры запуска.
firstvds.ru/technology/kak-ustanovit-i-zapustit-vllm

Habr: самое интересное за июнь
Ловите подборку из нашего блога на Хабре. Гвоздь программы — статья о том, как мы взяли L40S и vGPU на 16 ГБ и прогнали через бенчмарки в реальных задачах. Далее — пара рабочих гайдов: как ускорить сайт через оптимизацию изображений и как организовать личный CI/CD. Бонусом — необычная история о математике и плагиате.

Ищем авторов для блога на Хабр.

Подготовьте статью на одну из специальных тем или отправьте материал на тему месяца. И если ваша статья подойдёт для блога, вы получите повышенный гонорар.
Тема июля: Алгоритмы.
firstvds.ru/avtoram

Новости июня
Запустили новую услугу — «Мониторинг сайтов»

Теперь следить за доступностью сайта, сервера, домена и SSL-сертификата можно в одной панели. Сервис работает 24/7, отслеживает четыре ключевых параметра и при появлении проблем сразу отправляет уведомления на email, в телеграм, VK и другие каналы. Это помогает быстрее замечать сбои, не тратить время на ручные проверки и снижать риск простоев.
firstvds.ru/services/site-monitoring

Кешбэк до 10% по выходным в течение всего лета

Летние выходные стали ещё приятнее. Каждую пятницу, субботу и воскресенье за пополнение баланса (на рекомендуемую сумму и выше) можно получить кешбэк до 10%. Посмотреть рекомендуемую сумму можно через форму пополнения баланса на сайте или в Личном кабинете.
Процент кешбэка выше, если оплачивать услуги через СБП. Акция продлится до 30 августа.

Добавили новые рецепты для автоустановки на сервере

В июне мы добавили три новых рецепта для быстрого развёртывания популярных сервисов на VDS. При заказе сервера просто выбираете нужный рецепт и получаете VDS с уже предустановленным ПО. Все рецепты — бесплатные.
OpenClaw и Hermes Agent — self-hosted платформы для ИИ-агентов. Обе позволяют общаться с ассистентом через веб-интерфейс или в телеграме. Встроенные инструменты включают поиск в интернете и работу с файлами. OpenClaw интегрируется с Gmail, GitHub и другими сервисами, а также даёт доступ к агенту через API. Hermes Agent умеет подключаться к терминалу сервера и планировщику задач cron, что удобно для автоматических фоновых сценариев.
n8n — open-source платформа для автоматизации без кода. Поможет создать сценарии из готовых блоков в визуальном редакторе: от сбора данных по расписанию до отправки уведомлений и резервного копирования.

Доступна регистрация домена на родном языке

Теперь зарегистрировать сайт или почту можно на родном языке — без транслита и искажений. В зону.РФ добавлены буквы абазинского, татарского, чеченского, якутского и ещё 13 языков. А также 26 новых кириллических символов. Меньше барьеров, больше родного языка в интернете.
firstvds.ru/services/domain_names
Важно: С 1 сентября вступят в силу требования ФЗ № 569: владельцам доменов придётся проходить обязательную идентификацию через Госуслуги. Оформляйте домен на реальные данные, чтобы избежать проблем в дальнейшем.

Июньские изменения: что важно знать

Жизнь не стоит на месте, и июнь 2026-го — очередное тому подтверждение. Собрали самое важное в одном месте, чтобы вы были в курсе изменений и могли заранее к ним подготовиться.
О частичной недоступности ресурсов по HTTPS
С 1 июля повысятся цены на VDS и объектное хранилище S3
Новые правила работы с SSL-сертификатами

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

Один HTTP-запрос открывает доступ к любому аккаунту в phpBB
В свободном движке для форумов phpBB нашли уязвимость обхода аутентификации. Одним HTTP-запросом атакующий подключается к сессии любого пользователя форума, включая администратора. Проблема проявляется в конфигурации по умолчанию — никаких специальных условий или знания внутреннего устройства платформы не требуется. По данным исследователей, ошибка прожила в кодовой базе около десяти лет.
Метод эксплуатации уже воссоздали с помощью ИИ на основе патча. Запрос идёт к обработчику login_link с методом аутентификации auth_provider=apache, а логин подставляется через Basic Auth. После этого PHP выставляет переменную окружения PHP_AUTH_USER, и phpBB достаёт из неё логин без проверки пароля.
Уязвимость затрагивает все версии веток 3.x и 4.x вплоть до phpBB 3.3.16 и 4.0.0-a2. Перехват сессии обычного пользователя даёт доступ к приватной переписке и возможность писать от его имени. С сессией модератора или администратора добавляются удаление чужих сообщений, просмотр IP-адресов и email, чтение приватной переписки. Но даже админская сессия не открывает саму панель администрирования: вход в неё защищён отдельной проверкой пароля, поэтому до хоста и удалённого выполнения кода баг не доводит. Искать жертв несложно — список участников на форумах phpBB по умолчанию открыт всем.
Уязвимость обнаружили в начале июня специалисты компании Aikido и через программу bug bounty на HackerOne передали данные разработчикам. Те отреагировали быстро: уже 6 июня вышел патч в составе версии 3.3.17. Крупные форумы исследователи предупредили напрямую.
Что делать: обновиться до версии 3.3.17. Для ветки 4.x стабильного исправления пока нет, поэтому пользователям рекомендуют перейти на актуальную версию. После обновления некоторые форумы могут столкнуться с проблемами в работе OAuth-аутентификации — это связано с переносом обработчика OAuth-переадресации.
www.opennet.ru/opennews/art.shtml?num=65667
xakep.ru/2026/06/16/phpbb-auth-bypass/

В AUR захватили 1577 пакетов и раздавали из них вредонос
AUR (Arch User Repository) массово скомпрометировали — через этот репозиторий в Arch Linux распространяют приложения от сторонних разработчиков. Атакующие получили контроль примерно над 1577 пакетами и внедрили в них код для кражи паролей и ключей доступа. Среди затронутых оказался ALVR — пакет, популярный у любителей компьютерных игр.
Схема простая. Атакующие брали на себя заброшенные пакеты со статусом orphaned: указывали имя прежнего мейнтейнера, но другой email, добавляли один коммит и публиковали обновление. Коммит добавлял npm в зависимости PKGBUILD и вставлял в post_install-блок скрипта install.sh установку нескольких NPM-пакетов. Среди них — один-два легитимных и пакет atomic-lockfile или js-digest со скрытым вредоносным ПО. Установку прописывали во все скомпрометированные проекты, даже туда, где JavaScript и NPM не используются.
После активации вредонос закреплялся в системе как сервис systemd со случайным именем и маскировался под поток ядра. С правами root он создавал сервис на системном уровне (/etc/systemd/system) и дополнительно поднимал rootkit уровня ядра; с правами пользователя — запускал его от имени пользователя (~/.config/systemd/user). Дальше он сканировал систему и отправлял на внешний сервер ключи и учётные данные VPN, Docker, Podman и SSH, конфиденциальные данные из браузера, историю команд shell, ключи криптокошельков и токены доступа к Slack, Microsoft Teams, Discord, GitHub, NPM и Vault.
Масштаб рос на глазах: загрузку вредоносного js-digest успели внедрить в 879 пакетов, общее число захваченных оценивают в 1577. Первой волны не хватило — позже подставили код ещё в 54 пакета, на этот раз через зависимость bun и обфусцированную строку с установкой через bun add. Разработчики Arch Linux принимают меры, поэтому до окончательного решения возможны проблемы с регистрацией новых учётных записей в AUR, отправкой обновлений и созданием пакетов.
www.opennet.ru/opennews/art.shtml?num=65670

Дыра в JCE для Joomla открывает прямой путь к веб-шеллу
В JCE (Joomla Content Editor) — одном из старейших и популярнейших расширений Joomla — устранили критическую уязвимость CVE-2026-48907. Она позволяла импортировать профиль без аутентификации: атакующий заливал профиль, который отключал проверку MIME-типов и разрешал загрузку PHP-скриптов на сервер. Уязвимость успели взять на вооружение — зафиксированы реальные атаки, в которых злоумышленники ставили веб-шелл и получали удалённый доступ к системе. Затрагивает все версии JCE — от Joomla 3 до Joomla 6.
Что делать: обновиться до выпуска 2.9.99.5, следом за которым вышло обновление 2.9.99.6 с усилением защиты. После обновления стоит убедиться, что система не скомпрометирована и в ней не остался бэкдор:
  • проверить подставной профиль (как правило, у него бессмысленное автоматически сгенерированное имя): Компоненты → Редактор JCE → Профили редактора;
  • убедиться, что в параметре Разрешённые расширения файлов нет разрешения на загрузку PHP-файлов;
  • просмотреть логи на предмет запросов к URL импорта профилей: index.php?option=com_jce&task=profiles.import;
  • проверить сайт на сторонние .htaccess и файлы с именами, типичными для WordPress, а не Joomla, — например, wp-config.php и wp-cron.php.
www.opennet.ru/opennews/art.shtml?num=65715

Один восклицательный знак в ядре Linux открывает путь к root
Исследователи Exodus Intelligence разобрали уязвимость CVE-2026-23111 в подсистеме nf_tables. Это механизм пакетной фильтрации в ядре Linux: он управляет правилами брандмауэра и сменил iptables, ip6tables, arptables и ebtables. Виной всему один лишний восклицательный знак в коде — из-за него возникла ошибка use-after-free. Она позволяет непривилегированному пользователю или процессу поднять права до root.
Уязвимость ломает процесс удаления вердиктов — определений, которые решают, подходит ли пакет под правило. В нём участвуют элементы catchall: они работают как подстановочный знак, когда совпадений с другими элементами набора нет. Когда карта вердиктов удаляется из памяти, catchall-элементы деактивируются, а счётчик ссылок цепочки уменьшается. Если при удалении возникает ошибка, операция отменяется, а счётчик возвращается обратно. CVE-2026-23111 позволяет вмешаться в этот процесс: эксплойт уменьшает счётчик произвольное число раз, а затем удаляет и освобождает цепочку, хотя часть объектов всё ещё на неё ссылается. Так и появляется обращение к уже освобождённой памяти.
Если верить Exodus Intelligence, эксплойт многократно срабатывает на этой уязвимости и приводит к утечке базового адреса ядра, затем адресов кучи и перехвату потока управления. На неактивной системе авторы добились стабильности выше 99 %. Уязвимость воспроизводится на Debian и Ubuntu.
Уязвимость закрыли в ядре ещё в феврале. В апреле эксплойт продемонстрировала компания FuzzingLabs, а затем собственный рабочий эксплойт опубликовала и Exodus Intelligence — он тоже работал на Debian и Ubuntu.
Такие баги особенно опасны в связке: вместе с отдельным эксплойтом они позволяют обходить встроенную защиту операционной системы.
Что делать: Исправление вышло ещё в феврале — установите обновление ядра.
3dnews.ru/1143264/v-yadre-linux-nashli-seryoznuyu-uyazvimost-sozdannuyu-vsego-odnim-lishnim-simvolom-v-kode/

Гонка в процессорах ARM выпускает гостя за пределы виртуальной машины
Компания ARM раскрыла уязвимость CVE-2025-10263 в своих процессорах. Она позволяет писать в ресурсы, принадлежащие более высокому уровню исключений (Exception Level), и так повышать привилегии в системе. В связке с гипервизором Xen последствия еще более серьёзные: гостевая система может писать в память гипервизора.
В основе — рассинхронизация при операции TLBI (TLB Invalidation), которая очищает запись в кэше трансляции адресов (TLB). Инструкция DSB (Data Synchronization Barrier) подтверждает выполнение TLBI. Но на одном процессорном ядре она может отработать раньше, чем запись с другого станет видна всей системе. Из-за этого запись успевает пройти уже после того, как доступ был закрыт через TLBI.
Из-за этой рассинхронизации можно обойти сразу несколько барьеров защиты памяти: ограничения на уровне хоста (Stage 1) и виртуальной машины (Stage 2), а также защиту целостности памяти GPT (Granule Protection Table). На практике это выглядит так. Гипервизор командой TLBI закрывает виртуальной машине доступ к памяти. Система подтверждает, что доступ прекращён, — но гостевая ВМ всё равно продолжает туда писать.
Проблема проявляется только на многоядерных процессорах Arm: C1-Ultra, C1-Premium, Neoverse V3 и V3AE, Neoverse V2, Neoverse V1, Neoverse N2, Neoverse N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 и X1C, Cortex-A710, Cortex-A78, A78AE и A78C, Cortex-A77, Cortex-A76 и A76AE, а также NVIDIA Olympus.
Что делать:
  • Для гипервизора Xen исправление уже выпущено — установите его.
  • Для ядра Linux патч предложен, но в штатные обновления пока не вошёл — следите за апдейтами своего дистрибутива.
www.opennet.ru/opennews/art.shtml?num=65660

Червь mini-shai-hulud в 32 NPM-пакетах Red Hat
Злоумышленники скомпрометировали сборку релизов на GitHub Actions в репозиториях Red Hat (аккаунт RedHatInsights на GitHub). В результате в каталог NPM попали 64 вредоносные версии 32 пакетов для платформы Red Hat Cloud Services.
В код встроили новый вариант червя mini-shai-hulud. Об аналогичной атаке мы уже писали: тогда червь прошёл через пакеты TanStack и зацепил GitHub и OpenAI.
Новый вредонос ищет токены и учётные данные в окружении. Червь размещается в файле index.js и активируется через preinstall-обработчик при установке поражённого пакета. После запуска он ищет в системе токены к NPM (~/.npmrc), PyPI, CircleCI, AWS, GCP, Docker, Azure, HashiCorp и Kubernetes, а также закрытые ключи SSH, и отправляет найденное злоумышленникам. Если червь находит токен к NPM, он сам публикует новые вредоносные релизы для пакетов из текущего окружения — и так заражает дерево зависимостей.
Доступ к GitHub Actions злоумышленники получили через скомпрометированную учётную запись сотрудника Red Hat. Это позволило отправлять коммиты в репозитории javascript-clients, frontend-components и platform-frontend-ai-toolkit напрямую, в обход рецензирования. Через коммиты подставлялся файл ci.yaml, который при сборке запускал с помощью bun скрипт _index.js. Скрипт использовал полномочие id-token: write, чтобы запросить у GitHub токен OIDC (OpenID Connect), а затем применял его для аутентификации в NPM по механизму trusted publishing.
Кого затронуло: всех, кто устанавливал поражённые версии пакетов @redhat-cloud-services/*. Полный список из 32 пакетов с заражёнными версиями — тут.
Как защититься:
  • Проверить, не установлены ли перечисленные версии. Если установлены — считать все токены и учётные данные на этой машине скомпрометированными и сразу их перевыпустить.
  • Закрепить конкретные версии зависимостей и переходить на чистую установку из локфайла (npm ci).
  • По возможности отключить выполнение установочных скриптов сторонних пакетов (npm install --ignore-scripts).
www.opennet.ru/opennews/art.shtml?num=65599

Захват WordPress-сайтов через плагин WP Maps Pro
В популярном плагине WP Maps Pro для WordPress нашли критическую уязвимость, которую злоумышленники уже эксплуатируют в реальных атаках. Баг позволяет без аутентификации создать на сайте учётную запись администратора и получить полный контроль над ресурсом.
Уязвимость получила идентификатор CVE-2026-8732 и оценку 9,8 балла по шкале CVSS. Под ударом — все версии WP Maps Pro до 6.1.0 включительно. Сам плагин коммерческий, его используют, чтобы встраивать на сайты карты Google Maps и OpenStreetMap, а также создавать локаторы магазинов и каталоги точек продаж.
Проблему обнаружил ИБ-исследователь Дэвид Браун (David Brown). По его словам, корень бага — в функции временного доступа для техподдержки, через которую специалисты разработчика подключаются к сайту клиента для диагностики. Реализация оказалась небезопасной: AJAX-эндпоинт был доступен неавторизованным пользователям и защищался только nonce-токеном, который через JavaScript публиковался на всех страницах сайта. В итоге проверка не давала реального контроля доступа.
Для эксплуатации хватало одного запроса с параметром check_temp=false. После этого плагин создавал нового пользователя с жёстко заданной ролью администратора, генерировал для него magic-ссылку и возвращал её в ответе. При переходе по ссылке WordPress авторизовал пользователя автоматически — ни пароль, ни дополнительные проверки не требовались. Получив права администратора, атакующий мог ставить вредоносные плагины, размещать веб-шеллы, внедрять бэкдоры, красть данные пользователей или полностью перехватить управление сайтом.
Кого затронуло: сайты на WordPress с установленным WP Maps Pro версии 6.1.0 и ниже. Атаки уже идут: в Wordfence сообщили, что за сутки заблокировали около 2858 попыток эксплуатации, а специалисты Defiant за тот же период зафиксировали более 3600 атак.
Как защититься: обновить WP Maps Pro до версии 6.1.1 или новее — патч вышел 20 мая 2026 года и ограничил доступ к проблемному эндпоинту только авторизованными администраторами. Учитывая, что эксплуатация уязвимости уже началась, откладывать обновление не стоит.
xakep.ru/2026/06/04/wp-maps-pro/

HTTP/2 Bomb: атака, которая исчерпывает память сервера
Раскрыта информация об уязвимости HTTP/2 Bomb, которая затрагивает разные реализации протокола HTTP/2 и позволяет добиться отказа в обслуживании, исчерпав всю доступную процессу память. Проблему подтвердили в конфигурации по умолчанию у nginx, Apache httpd (CVE-2026-49975), Microsoft IIS, Envoy (CVE-2026-47774) и Cloudflare Pingora.
Метод напоминает zip-бомбу, только применённую к сжатию заголовков в HTTP/2. Запрос может содержать тысячи сжатых заголовков (например, Cookie) без полезных данных. Каждый такой заголовок в запросе — это однобайтовая ссылка в индексе HPACK, но на сервере под него выделяется память под весь заголовок целиком. Отсюда и многократное усиление: на каждый байт в индексе сервер тратит куда больше.
Кого затронуло: перечисленные HTTP-серверы в конфигурации по умолчанию. Сервер Angie уязвимости не подвержен — защиту от этой атаки в него перенесли из freenginx ещё в версии 1.8.0 в 2024 году. Позднее наличие проблемы подтвердили и в HTTP-сервере h2o.
Как защититься:
  • nginx — обновиться до 1.29.8: туда из freenginx перенесли директиву max_headers, которая по умолчанию допускает не более 1000 заголовков.
  • Envoy — обновиться до 1.35.11 или 1.36.7 с лимитами mutable_max_request_headers_kb и max_headers_count.
  • Cloudflare Pingora — обновиться до 0.8.1, куда добавили ограничения, блокирующие атаку.
  • Apache httpd — исправление готово в модуле mod_http2 2.0.41, но в релизы Apache httpd оно ещё не вошло. До выхода релиза обновление сервера дыру не закроет — остаётся обновить mod_http2 вручную или использовать обходной путь (ниже).
  • Microsoft IIS — исправления пока нет.
  • h2o — исправление доступно в виде патча.
  • В качестве обходного пути можно отключить HTTP/2 и выставить ограничение на объём памяти для рабочих процессов.

Новая услуга — «Мониторинг сайтов»



Теперь в одной панели можно следить за доступностью сайта, сервером, SSL-сертификатом и доменом.
Сервис работает 24/7 и отслеживает:
  • URL
  • Ping
  • SSL
  • Domain
Если возникает проблема, сервис сразу отправляет уведомление в выбранный канал связи: Email, Telegram, VK, MAX, Slack или webhooks. Это помогает быстрее замечать сбои, не тратить время на ручные проверки и снижать риск простоев.
firstvds.ru/services/site-monitoring


Сервис находится в стадии MVP, и ваша обратная связь поможет нам сделать продукт лучше. До 13.07.26 включительно предлагаем вам поискать баги (как вы любите). За активность конструктивность мы обязательно порадуем вас бонусом в течение срока тестирования либо после окончания теста. Вступить в группу тестировщиков в телеграм t.me/+Dk2H0nypfLs0ZmJi