Компания ISPsystem — разработчик платформы серверной виртуализации VMmanager — подтверждает информацию об инциденте, связанном с уязвимостью в одной из сборок VMmanager 6, и сообщает о принимаемых мерах.

Нам известно об инциденте, связанном с уязвимостью в одной из сборок VMmanager. Мы проводим проверку и находимся в постоянном контакте с заказчиками.

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

Для всех инсталляций в обязательном порядке на период инцидента необходимо:

• На межсетевом экране в инфраструктуре закрыть доступы к платформе и узлам виртуализации для всех, кроме доверенных администраторов и технической поддержки ISPsystem, как на входящие, так и на исходящие соединения.
• Разрешить SSH-доступ к узлам и платформе управления только с доверенных адресов.

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

Мы остаёмся на связи со всеми заказчиками и призываем пользователей при малейшем подозрении обращаться в техническую поддержку вендора.

1. Работа вендора над устранением уязвимости всё еще продолжается.

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

3. Параллельно отдел эксплуатации пересматривает политики безопасности внутренней инфраструктуры с учётом новых угроз и готовит доработки внутренней сети и систем обслуживания серверов.

4. Заказ виртуальных серверов доступен. Обработка и выдача серверов пока может занимать больше времени, чем обычно.

5. Поддержка работает в обычном режиме, создавать обращения снова можно. Если нагрузка резко вырастет, мы можем на время приостановить приём новых обращений, чтобы быстрее ответить на уже поступившие. В это время общие вопросы по инциденту можно задать в нашем Telegram-чате. Вопросы по конкретным услугам решаем только через обращения.

https://firstvds.ru

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

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

Что пока остаётся недоступным?
Работы по восстановлению доступа к панели управления виртуальными серверами продолжаются совместно с вендором.

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

• Перезагрузка виртуального сервера.
• Смена пароля.

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

cloud4box.com

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

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

Тем не менее, для обеспечения максимального уровня защиты и минимизации рисков в будущем, мы настоятельно рекомендуем вам провести превентивные меры безопасности:

• Обновите пароли: Смените root-пароли на ваших виртуальных машинах и учетные записи в панелях управления на более сложные.
• Проверьте права доступа: Убедитесь, что к вашим проектам имеют доступ только актуальные сотрудники. Удалите старые или неиспользуемые учетные записи.
• Настройте двухфакторную аутентификацию (2FA): Включите двухэтапную проверку для аккаунтов везде, где это поддерживается.
• Контролируйте SSH-ключи: Проверьте список разрешенных SSH-ключей в файлах authorized_keys на ваших серверах на предмет наличия незнакомых записей.

Мы продолжаем непрерывный мониторинг состояния сети и платформ управления. Благодарим вас за доверие и выбор нашей компании.

С уважением,
Служба технической поддержки и безопасности

https://billing.elenahost.ru

Здравствуйте!
Просим внимательно прочитать это письмо.
В панели управления серверами VMmanager, которую мы используем cloudpanel.pro обнаружена уязвимость в системе безопасности. Ее допустили разработчики панели.
Мы сразу приняли все необходимые меры. Панель управления отключена до тех пор, пока наша команда безопасности не завершит анализ.
Ваши серверы

• Виртуальные серверы не затронуты и работают как обычно.
• Отключение панели на их работу не влияет.

Что рекомендуем сделать
Для дополнительной защиты настоятельно просим:

• 1. Сделать полную резервную копию всех важных данных в отдельное хранилище, например на другой сервер или на ваш компьютер.
• 2. Сменить пароли и SSH-ключи доступа к серверу.

Так мы вместе обеспечим максимальную безопасность ваших данных.

Мы продолжаем анализ ситуации и будем держать вас в курсе.
Если остались вопросы, создайте тикет в личном кабинете.
Спасибо за понимание!

Команда SpaceCore
Техническая поддержка

Control Panel Temporarily Disabled
Hello
Please read this message carefully. It contains important information.
A security vulnerability has been discovered in VMmanager, the server control panel we use cloudpanel.pro The vulnerability was introduced by the panel's developers.
We took immediate action to protect your services. The control panel has been taken offline until our security team completes its analysis.
Your servers

• Your virtual servers have not been affected and continue to run normally.
• Taking the panel offline does not affect their operation.

What we recommend
As an additional precaution, we strongly recommend that you:

• 1. Make a full backup of all important data and store it separately, for example on another server or on your local computer.
• 2. Change your server passwords and SSH keys.

These steps will help keep your data as secure as possible.

We are continuing our investigation and will keep you informed.
If you have any questions, create a ticket in your account.
Thank you for your understanding.

SpaceCore Team
Technical Support

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

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

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

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

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

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

Что осталось неизменным
Наше расследование показало, что инцидент не затронул:

• резервные серверы;
• персональные данные, хранящиеся в клиентском портале;
• платежные реквизиты;
• сервисы, помимо затронутой платформы управления виртуализацией.

В данном случае важно разделение этих систем. Доступ к части среды управления виртуализацией не предоставлял доступа к данным о выставлении счетов, данным учетных записей клиентов или инфраструктуре резервного копирования.

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

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

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

Автоматический доступ через клиентский портал ITLDC продолжает работать как и прежде. Клиенты могут открывать свой интерфейс управления VDS через портал без ввода прежнего пароля для прямого доступа.

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

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

Если тот же пароль использовался в другом месте, измените его и там. Замена одной копии не сделает другие копии менее уязвимыми.

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

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

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

Также проверьте системы развертывания, скрипты, задания CI/CD и конфигурации агентов, которые могут содержать копии старого ключа.

3. Меняйте учетные данные приложения и внешних сервисов.
Замените конфиденциальные данные аутентификации, хранящиеся на виртуальном сервере. Это может включать в себя:

• Ключи API и токены доступа;
• Учетные данные для облачных сервисов и объектных хранилищ;
• Пароли к базам данных;
• учетные данные для внешних панелей управления и сервисов;
• закрытые ключи, используемые приложениями;
• Секреты веб-хуков и ключи подписи.

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

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

4. Проверьте резервные копии.
Убедитесь, что у вас есть актуальные резервные копии всех необходимых данных, что вы можете получить к ним доступ и что они хранятся в независимом месте. Резервной копии, находящейся в том же домене отказоустойчивости, что и производственная система, недостаточно для серьезных сценариев восстановления.

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

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

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

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

Если у вас возникли трудности с доступом к интерфейсу управления VDS или вам требуется уточнение информации о вашем сервисе, пожалуйста, свяжитесь со службой поддержки ITLDC через клиентский портал.

itldc.com

18 октября Взлом хостинг-провайдеров через VMmanager 6: что произошло, что мы сделали и что следует предпринять вам
В ночь с 16 на 17 октября злоумышленники атаковали хостинг-провайдеров, использующих VMmanager 6 — панель управления ISPsystem, которая обслуживает VPS для нас и многих других провайдеров. Они заразили панели заранее, с 11 по 16 октября, через критическую уязвимость: они получили доступ к базе данных панели, а у некоторых провайдеров — и к узлам с клиентскими серверами. Мы тоже пострадали. Мы провели расследование вместе с коллегами: в общем чате участвовали 37 человек из разных хостинг-компаний, некоторые из которых управляют более чем 30 000 машинами.

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

Что просочилось в сеть
Злоумышленники получили доступ к базе данных панели:

• список серверов и их IP-адреса;
• адреса электронной почты учетных записей участников панели;
• Пароли root, устанавливаемые через панель управления — при заказе, переустановке или изменении пароля;
• Пароли консоли VNC.

У некоторых провайдеров злоумышленники также получили доступ к узлам и запустили там сборщик данных. Он искал секретные данные на дисках клиентских машин:

• Доступ и пароли: ключи SSH, authorized_keysхэши системных паролей, сохраненные пароли от баз данных и Git, менеджеры паролей, ключи GnuPG.
• Облачные технологии и DevOps: учетные данные AWS, Google Cloud, Azure, OpenStack, Kubernetes, Docker и Terraform, токены npm, GitHub и GitLab.
• Приложения и базы данных:.env файлы, конфигурации подключения к приложениям и базам данных, docker-compose.ymlконфигурации хранилища (Vault).
• Криптовалюта: файлы кошелька, сид-фраза и мнемонические фразы, ключи валидатора, ключи API биржи.
• История браузеров: сохраненные в браузерах пароли и файлы cookie, история работы командной оболочки и клиентских баз данных.
• Ключи внутри файлов: закрытые ключи, токены GitHub, GitLab и Slack, ключи AWS и ключи API сервисов искусственного интеллекта, строки подключения к базе данных и Redis, пароли для резервного копирования restic и Borg.

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

На собственном сервере панели сборщик данных был запущен с правами root вечером 16 октября. На этом сервере, за исключением базы данных панели, нет никаких клиентских данных, и мы выполнили ротацию всего, что было на нем связано с сервисом — см. ниже.

Как всё это развернулось

• 11–16 октября. Злоумышленники заразили панели VMmanager 6 через уязвимость. Первые следы атаки датируются 12 октября; вечером 16 октября сборщик вредоносного ПО запустился на сервере нашей панели.
• Ночь с 16 на 17 октября. Атака на хостинг-провайдеров: злоумышленники проникли в базы данных панелей, а у некоторых провайдеров — и в узлы с клиентскими серверами.
• 17 октября. Мы обнаружили взлом и закрыли публичный доступ к панели. Мы нашли и устранили доступ злоумышленников и восстановили произошедшее по журналам и резервным копиям.
• В ночь с 17 на 18 октября компания ISPsystem выпустила исправление — версию 2026.05.2-6. Мы установили его, убедились, что уязвимость устранена, и сменили ключи и пароли сервисов.
• 18 октября. Приём заявок возобновляется.

Что мы сделали

• Установил исправление от производителя в тот же вечер, когда оно пришло, и убедился, что отверстия закрыты.
• Произведена ротация всех данных, хранящихся на сервере панели управления: ключей доступа к узлам, паролей служб интеграции с системами выставления счетов и поддержки, DNS-ключей и ключей резервного копирования.
• Панель была повторно открыта только через Cloudflare с дополнительной фильтрацией.
• Проверили каждый узел, на котором работают клиентские серверы, и не обнаружили никаких признаков вмешательства.
• Личный кабинет и платежная система на my.forestsnet.cloud работают на отдельном сервере, и панель управления не имеет к нему доступа.

Что вам следует сделать

• Если вы установили пароль root в панели управления и с тех пор его не меняли, измените его — даже если на сервере всё выглядит нормально.
• Переключитесь на вход по SSH-ключу. И отключите вход по паролю — см. раздел «Как повысить безопасность SSH».
• Обновите секретные данные, хранившиеся на сервере: SSH-ключи, токены и API-ключи, пароли к базам данных, учетные данные для облачных сервисов и CI. Если на сервере хранились кошельки или сид-фразы, переведите средства на новые адреса.
• Проверьте сервер: незнакомых пользователей, ключи ~/.ssh/authorized_keys, задания cron, незнакомые процессы и службы. Шаг за шагом — в контрольном списке безопасности VPS .
• У вас есть серверы других провайдеров, работающие в VMmanager 6? Выполните те же действия и там.

17 октября Аварийная перезагрузка узла: уязвимость ядра PwnEscape устранена
17 октября с 14:07 до 14:28 UTC мы поочередно перезагрузили все узлы хостинга — два в Нидерландах и один в Германии. Виртуальные машины корректно завершили работу и запустились сразу после восстановления работы узла, поэтому каждая из них была недоступна примерно пять-шесть минут. Мы не смогли предупредить вас заранее, и приносим свои извинения за это.
Что случилось
В сетевом стеке ядра Linux обнаружена критическая уязвимость — PwnEscape, CVE-2026-99999, получившая оценку 9,3 из 10 по шкале CVSS. Изнутри виртуальной машины она позволяла считывать память физического узла, вызывать сбой узла вместе со всеми соседними машинами или выполнять код на самом узле. Ошибка находится не в гипервизоре или панели управления, а в ядре: она существовала в коде около восемнадцати лет и затрагивает все текущие версии.
Почему сразу, а не ночью?
Обходного пути нет: только новое ядро ​​закрывает уязвимость, и это вступает в силу после перезагрузки. Компания AlmaLinux выпустила исправленное ядро ​​вечером 16 октября; мы установили его и перезагрузили узлы на следующий день. Ожидание ночного окна оставило бы каждый сервер уязвимым еще на один день.

7 октября Тест скорости и Looking Glass — теперь прямо на сайте
Перед покупкой сервера полезно знать, как ваша сеть обеспечивает связь с местоположением. Теперь вы можете проверить это, не покидая веб-сайт: forestsnet.cloud предлагает тест скорости и функцию Looking Glass.
Тест скорости измеряет ваше соединение с нашими серверами в Эйгельсховене и Франкфурте за полминуты — прямо в браузере, без необходимости установки чего-либо.
forestsnet.cloud/en/speedtest
Пинг, дрожание сигнала, загрузка и выгрузка. Данные передаются по нескольким потокам, и сервер сам подсчитывает байты — поэтому эти числа не завышены из-за буфера браузера.
Пинг под нагрузкой. Показывает, есть ли задержки в сети во время загрузки чего-либо — это важно для игр, звонков и удаленной работы.
Маршрут на глобусе. Какие города и сети проходят от сервера к вам, с указанием точек обмена интернет-трафиком и задержки на каждом сегменте.
Оценка соответствия вашей задаче. Веб-сайт или API, игровой сервер, удаленный доступ, потоковая передача, резервное копирование — мы сообщим вам, подходит ли данное местоположение.
Сравниваем местоположения. Проведите тест в обоих местах и ​​посмотрите, где соединение лучше.
Зеркало
Приложение Looking Glass выполняет команды ping, traceroute и MTR с наших серверов определения местоположения до любого адреса — например, до вашего провайдера, веб-сайта или сервиса. По умолчанию заполняется ваш IP-адрес, который показывает обратный путь от нашего сервера к вам.
В комплект также входят тестовые файлы размером 100 МБ и 1 ГБ, а также команды iperf3 для проверки сервера с вашей стороны.
forestsnet.cloud/en/looking-glass

7 октября Соглашение об уровне обслуживания (SLA) с вероятностью неудовлетворительных результатов 99,8% и обновленная версия Условий предоставления услуг
С 15 октября 2026 года у ForestsNet Cloud действует Соглашение об уровне обслуживания (SLA), а также обновленная версия Условий предоставления услуг. Вот что это значит для вас.
Что обещает соглашение об уровне обслуживания (SLA)

• 99,8% в месяц. Это гарантированная доступность каждого сервера — не более полутора часов простоя в месяц.
• Мы отвечаем за наших поставщиков. Сбой, вызванный работой дата-центра или наших подрядчиков, также считается простоем, и именно мы оплачиваем компенсацию за него.
• Прозрачное измерение. Доступность измеряется нашей системой мониторинга, которая проверяет узлы каждые 30 секунд; история инцидентов отображается на странице состояния.

Компенсация за время простоя
Если доступность сервера в течение календарного месяца падает ниже 99,8%, на ваш баланс добавляется сумма, рассчитанная исходя из ежемесячной стоимости этого сервера:

• ниже 99,8% — 10%;
• ниже 99,0% — 25%;
• ниже 95,0% — 50%.

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

• Плановое техническое обслуживание, о котором сообщается не менее чем за 48 часов — до 4 часов в месяц; ваши собственные настройки и перезагрузки; DDoS-атаки на ваш сервер; блокировка наших адресов в определенных странах; и форс-мажорные обстоятельства. Полный список содержится в соглашении об уровне обслуживания (SLA).

Что изменилось в Условиях?

• Данные и резервные копии. Вы по-прежнему можете создавать резервные копии самостоятельно: регулярно и не на том же сервере. Мы не храним копии ваших данных.
• Ответственность. В случае недоступности серверов вы получаете компенсацию в соответствии с соглашением об уровне обслуживания (SLA); общая ответственность ограничена суммой, уплаченной за 12 месяцев.
• Форс-мажорные обстоятельства и плановое техническое обслуживание. Список форс-мажорных обстоятельств стал более подробным, и теперь мы объявляем о плановом техническом обслуживании не менее чем за 48 часов.

1 октября Привяжите свой банковский счет через SBP: оплачивайте покупки без QR-кода и настройте автоматическую оплату
Теперь ваш аккаунт поддерживает сохраненные способы оплаты. Вы привязываете свой банковский счет один раз через СБП (Российская система быстрых платежей) и затем можете оплачивать покупки с него без QR-кода или подтверждения в банке. Ниже приведена пошаговая инструкция и три способа использования привязки.
Что можно делать с привязанным аккаунтом

• Оплата без QR-кода. При пополнении счета вы выбираете привязанный счет, и деньги списываются мгновенно, без QR-кода и подтверждения в вашем банке. Удобно для тех, кто пополняет счет вручную.
• Автоматическое продление серверов. В настройках сервера выберите связанный аккаунт в качестве способа оплаты, и сервер будет автоматически продлевать подписку с этого аккаунта. Для каждого сервера предусмотрены свои настройки, поэтому вы можете автоматизировать только нужные вам серверы.
• Включите автоматическое пополнение баланса. Когда на вашем счету будет недостаточно средств для предстоящего продления подписки, баланс будет пополняться с привязанного аккаунта. Это удобно, если у вас несколько серверов и вы не хотите постоянно следить за балансом.

30 сентября Правила использования сторонних доменов в настройках сервера: обновлены
В наши Условия предоставления услуг добавлен раздел о сторонних доменах. Главное: вы по-прежнему сами решаете, какое программное обеспечение и протоколы будут работать на вашем сервере. Правило касается только того, чей ресурс будет выбран в качестве целевого для подключения, и оно применяется также к личному использованию.
Что должны содержать ваши настройки
Все параметры, определяющие целевой ресурс соединения, должны указывать на ваш собственный ресурс: ваш домен и ваш веб-сервер, обычно расположенные на одном сервере. Использование стороннего домена или IP-адреса там не допускается. Это включает в себя:

• SNI и serverName;
• dest, targetи fallback;
• handshake domain;
• Сертификат TLS;
• любые другие настройки, выполняющие ту же функцию.

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

• Автоматически: каждые 3 часа мы проверяем, какой TLS-сертификат сервер предоставляет на общедоступных портах.
• На основании поступивших к нам сообщений о случаях насилия.
• Две недели, чтобы всё исправить.

До 23:59 UTC 15 октября 2026 года правило работает в режиме предупреждения. Если проверка обнаружит домен стороннего разработчика, служба поддержки откроет запрос, и у вас будет три дня на исправление настроек. После исправления вопрос закроется сам собой — писать нам не нужно. Если нарушение сохраняется и через три дня, сервис блокируется.
С 16 октября предупреждения больше не будут выдаваться: нарушение означает немедленную блокировку сервиса.
Блокировка является окончательной: услуга не восстанавливается, и возврат средств за оплаченный период не производится. Сервер отключается, и его данные в этот момент не уничтожаются, но его невозможно повторно запустить. Второго шанса нет, поэтому проверьте свои серверы сейчас, пока любую ошибку еще можно исправить бесплатно.
Проверьте свой собственный сервер.
Проверьте его IP-адрес на platform.censys.io, чтобы узнать, какие сертификаты используются для открытых портов. Или обратитесь к серверу напрямую: openssl s_client -connect IP:443 </dev/null | openssl x509 -noout -subjectдолжно отобразиться ваше собственное доменное имя.

9 августа Германия в прямом эфире — Франкфурт и скидка 20% в первую неделю
Запущен новый филиал: Германия, Франкфурт. Та же линейка EP-1…EP-5 на базе AMD EPYC 7713 по тем же ценам, что и в Нидерландах — теперь ближе к клиентам в Центральной Европе.
Что доступно

• Планы EP-1…EP-5 во Франкфурте — выберите местоположение прямо в таблице цен.
• Скорость порта можно выбрать при оформлении заказа: 1 / 2 / 5 / 10 Гбит/с.
• Приложение Looking Glass для нового сайта: de.lg.forestsnet.cloud — ping, MTR, traceroute и тест скорости.
• Мониторинг узла ведется круглосуточно — см. страницу состояния узла.

Скидка 20% на серверы в Германии
В течение первой недели получите скидку 20% на серверы во Франкфурте. Скидка распространяется и на дополнительный трафик, но не действует на продления — только на новые заказы. Тарифные планы в Нидерландах не входят в это предложение.
Условия

• Скидка 20% на серверы в Германии
• Также распространяется на скидку за проезд.
• Не распространяется на продление договоров и другие места.
• Действительно с 9 по 17 августа 2026 года.

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

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

• iCloud (@icloud.com, @me.com, @mac.com)
• Yahoo Mail
• Proton Mail (proton.me, protonmail.com)
• Яндекс Почта (@yandex.ru)
• Mail.ru (@mail.ru, @bk.ru, @inbox.ru, @list.ru)

Что делать дальше?
Если вы ждете электронное письмо, но не получили его, сначала проверьте папку «Спам». По возможности, зарегистрируйтесь в почтовом ящике другого провайдера (например, Gmail). Если письмо по-прежнему не приходит, свяжитесь с нашей службой поддержки, и мы поможем вам вручную.
Мы уже работаем над устранением проблемы и в ближайшее время восстановим надежную доставку. Приносим извинения за доставленные неудобства.

24 июля Облачное решение ForestsNet открыто — получите скидку 30% на первую покупку!
Скидка 30% в честь нашего запуска!
В честь запуска получите скидку 30% на первую покупку. Предложение распространяется на первые три сервера в вашем заказе.
Условия

• Скидка 30% на первую покупку
• Применяется к вашим первым трём серверам.
• Действительно с 24 июля по 1 августа 2026 года.

status.edgecenter.ru/incidents/2b3bacfd-d399-48bd-a6a9-2f7ba7a99c0a

update

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

17.10.2026
В ближайшее время решим проблему с обратными DNS записями.

Делаем плановое обновление ПО и ядра Linux на серверах виртуализации в целях безопасности.

После обновления сервера проходят физическую перезагрузку. VDS также перезагружаются. Недоступность обычно от 4 до 10 минут.

Перезагрузка необходима.
Просим отнестись с пониманием.

15.10.2026
Если использовали наши DNS сервера для доменов, а именно ns1.ihordns.net и ns2.ihordns.net, то в их работе наблюдается проблема на стороне регистратора домена NameCheap. Мы связались с регистратором для ее решения, но они неторопливые. Мы прилагаем усилия чтобы решить проблему быстрее и восстановить работу домена.

Решение следующее в моменте: обновить DNS сервера у вашего доменов на

• ns1.ihor-dns.net
• ns2.ihor-dns.net

Это пока оперативный путь решения.
Просим отнестись с пониманием.

Доступ в ру биллинг работает как и прежде по адресу: billing.ihor-hosting.ru
с DNS продолжаем разбираться, ожидаем ответа.

Затронуло локации нашего проекта

• Кемерово
• Москва Селектел
• Питер Селектел

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

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

• Мы рекомендуем сменить все свои пароли и ключи ваших проектов
• Так же поменять пароль своей VM
• И поменять пароль своего аккаунта VMmanager (кнопка перейти в биллинге, потом зайти в профиль, можно еще 2FA включить)

Хорошо описано что нужно менять в этом топике.