Рейтинг
0.00

Servers-com Хостинг

4 читателя, 67 топиков

Уведомление об изменении стоимости услуг



Настоящим выражаем вам свое уважение и, к большому сожалению, сообщаем об изменении стоимости услуг по договору о предоставлении платных услуг «SERVERS»: с 1 октября 2023 года стоимость услуг в Москве будет увеличена на 20%.

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

Будем благодарны за понимание и продолжение сотрудничества. Если данное изменение будет неприемлемо для вас – просим направить в наш адрес отказ от использования услуг в течении 10 календарных дней через ЭДО или скан-копию на адрес office@servers.ru.

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

Обновление - атака завершена, пожалуйста, найдите полный RCA здесь



Совместный анализ Qrator Labs и Servers.com первой значимой атаки DDoS в дикой природе с использованием определенного вектора усиления TCP

AMSTERDAM и PRAGUE, 21 августа 2019 г. / PRNewswire / — Servers.com и Qrator Labs делятся информацией о недавних атаках, чтобы другие могли подготовиться и быть готовыми к этому в будущем. Обе компании предоставляют подробную информацию и анализ первой значимой атаки DDoS в дикой природе с использованием одного из векторов усиления TCP. Ниже приводятся временные рамки, анализ и выводы, а также ряд шагов, предпринимаемых для значительного снижения вероятности того, что любой новый вид атаки существенно повлияет на доступность серверов клиентов.

Временное ограничение
Воскресенье, 18 августа 2019 г.
  • 07:00 UTC: злоумышленники начали атаковать сетевую инфраструктуру Servers.com, создавая регулярные всплески трафика с высокой скоростью передачи пакетов. Доступность услуг в сети Servers.com не изменяется.
  • 07:10 UTC: Servers.com обратился к Qrator Labs, намереваясь защитить определенные IP-префиксы с помощью службы Qrator Ingress, управляемой посредством объявлений BGP.
  • 13:07 UTC: изменение в атаке: система мониторинга Servers.com сообщает о комбинации UDP-потока и TCP-SYN / ACK-атаки. Некоторые сети Servers.com подвержены атакам.
  • 13:20 UTC: Servers.com реализует инструмент, который изолирует сети, затронутые атакой, от сетей, которые не были затронуты, чтобы ограничить влияние атаки на клиентов внутри атакуемых сетей. Клиентам внутри затронутых сетей рекомендуется перейти на незатронутые. С этого момента и до смягчения атаки злоумышленники периодически меняли список целевых и нецелевых сетей, поэтому процесс миграции изоляции повторялся.

Понедельник, 19 августа 2019 г.
  • 15:08 UTC: Первоначальное объявление затронутых префиксов IP-адресов Servers.com через все входящие потоки сети Qrator MSSP, кроме CenturyLink / Level3 (подробнее об этом ниже).
  • 17:48 UTC: первое появление атаки через сеть Qrator распознается как атака со смешанным усилением UDP с преобладанием трафика LDAP. Атака успешно смягчается и продолжается до 18:54 UTC.
  • 19:01 UTC: Первый тактический своп: усиление UDP заменяется на усиление SYN / ACK. Атака успешно смягчается, и стабильно продолжается до 20 августа 2019 года в 06:33 по Гринвичу в общей сложности 11,5 часов.

Вторник, 20 августа 2019 г.
  • 06:35 UTC: Второе изменение тактики: усиление SYN / ACK заменяется смешанным усилением TCP + UDP. Атака успешно смягчается и продолжается до 07:11 UTC.
  • 07:53 UTC: Третий обмен тактикой: атака с использованием ковровой бомбардировки нацелена на большее количество IP-сетей Servers.com.
  • 08:27 UTC: остальные префиксы Servers.com подвержены переадресации через Ingress. Атака успешно смягчается.
  • 10:45 UTC: связь CenturyLink / Level3 становится полностью работоспособной (см. Ниже).

Детали атаки
  • Атака в основном состояла из усиления LDAP (со значительной частью фрагментированных дейтаграмм UDP) и трафика усиления SYN / ACK, при этом периодически присутствовали другие виды усиления UDP.
  • Трафик усиления SYN / ACK достиг своего пика около 208 миллионов пакетов в секунду, возможно, исключая значительную часть трафика, исходящего из клиентского конуса уровня 3, из-за статических петель, предполагаемых перегрузок транзитной линии и других проблем маршрутизации (см. Ниже).

Основные проблемы, стоящие за усилением SYN / ACK (и потоками пакетов на основе TCP в целом):
  • Этот вид DDoS-атаки практически не поддается отслеживанию из-за низкого уровня применения методов противодействия спуфингу (таких как BCP 38). Поскольку предполагается, что эти подходы требуют существенного изменения сети при определенных обстоятельствах, колларально ломая вещи, которые являются более важными для сети, ожидается, что принятие этих подходов останется на низком уровне в обозримом будущем, если IETF не примет другое прочная конструкция против спуфинга;
  • Способность интернет-провайдера или центра обработки данных обрабатывать такого рода DDoS-атаки с помощью BGP Flow Spec (или аналогичных методов) зависит от того, какое конкретное оборудование используется в их сети;
  • Для значительной части клиентов критически важна возможность подключения к внешней службе или шлюзу API через TCP. Сканеры, такие технологии, как OAuth или CDN, или такие предприятия, как системы кредитного скоринга или страховые компании, сильно зависят от внешних баз данных (или источников данных в целом);
  • Чтобы обеспечить надлежащую обработку поддельных SYN / ACK при сохранении возможности подключения к внешней службе, атакующей хостинговой компании придется отслеживать все исходящие SYN, чтобы позже сопоставить их с полученными SYN / ACK.
  • Последнее может быть выполнено различными способами, каждый из которых считается либо сложным для проектирования и развертывания, либо оказывает серьезное влияние на задержку сети и RTT, либо и то и другое;
  • Коэффициент усиления для усиления SYN / ACK, отсутствующий в относительно редких угловых случаях, предполагается между 1x и 5x. Это не является значительным показателем по сравнению с NTP 500+ или Memcached '9000+. Однако, принимая во внимание остальную часть проблем и сложные меры по смягчению, пятикратная скорость передачи пакетов DDoS может стать поворотным моментом.

Ряд неудачных событий еще больше повлиял на график смягчения последствий атаки:
Сеть Qrator Labs работает через множество восходящих интернет-провайдеров Tier-1 (или региональных Tier-1), одним из которых является AS3356 CenturyLink (ранее Level3).
Автономные системы Qrator (в основном, AS200449) являются полностью многосетевыми и основаны на любых вещах и предназначены для работы с одной или несколькими вышестоящими сетями, имеющими TITSUP или перегруженными в любое время. Сказав это, 2019 год знаменует собой один год для Qrator как гордого клиента CenturyLink. CenturyLink предоставляет Qrator отличный сервис связи как в Соединенных Штатах, так и в Европе.

Что сильно повлияло на сроки смягчения, так это политика обновления фильтра префиксов CenturyLink на 48 часов. И Qrator, и Servers.com обратились к своим соответствующим контактным точкам на уровне 3, пытаясь сократить это время ожидания, однако (учитывая, что настройка службы смягчения для производственной сети началась в воскресенье в UTC), мы были невозможно значительно сократить время ожидания.

Изменения в разделе Профиль Личного кабинета



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

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

Отредактировать пользователей и их роли можно будет в Личном кабинете в разделе Профиль.

Всю дополнительную информацию вы можете найти в нашей Базе знаний www.servers.com/support/knowledge/accounts/user-management

Важные изменения: Переключение доменов на новые серверы имен с 5 сентября по 3 октября 2023



Мы запланировали работы по обновлению и замене DNS-серверов, которые обслуживают доменные имена в Portal.

Работы пройдут в 2 этапа и предполагают действия со стороны клиента.

Первый этап
5 сентября мы создадим копии ваших DNS-зон и обратных зон на наших новых NS-серверах. С этого момента любые изменения DNS-записей в разделе DNS в Portal, для которых указаны старые NS-серверы, не будут иметь силы.

Мы сообщим отдельно о завершении этого этапа работ, и затем вам будет необходимо переключить доменные имена у регистратора на новые NS:
ns1.srvrsdns.ru
ns2.srvrsdns.ru
ns3.srvrsdns.ru

До 3 октября DNS-зоны будут обслуживаться как старыми, так и новыми NS-серверами, однако изменения в DNS-зонах будут применяться только для тех зон, для которых будут настроены новые NS-серверы. Обратите внимание, что обновление информации о DNS-записях домена может занять до 72 часов.

Второй этап
3 октября мы начнем удаление всех DNS-зон со старых NS-серверов, что приведет к недоступности DNS-записей, которые обслуживались старыми NS-серверами. Восстановить работу таких DNS-записей будет возможно, переключив домены на новые NS-серверы у регистратора.

С уважением,
команда поддержки Servers.ru

Отчет по инциденту: AMS1 & Амстердам - зоны 1-4, публичная сеть - 11 июля 2022



11 июля 2022 мы зарегистрировали инцидент в локации AMS1 (Амстердам, Нидерланды), который также затронул облачные регионы Амстердам — зона 1-4. Произошел сбой в работе двух активных маршрутизаторов публичной сети. Сбой привёл к недоступности серверов по публичной сети.

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

Общее время ограничений составило 26 минут.

Хронология событий и восстановления сервисов:
  • 11 июля 2022, 15:57 (МСК) — началась массивная DDoS-атака на один из IP-адресов в локации AMS1, вследствие чего наша автоматическая система защиты применила ограничение для входящего трафика;
  • 11 июля 2022, 16:08 (МСК) — DDoS-атака завершилась, и автоматическая система защиты отменила ограничения для входящего трафика;
  • 11 июля 2022, 16:09 (МСК) — наша система мониторинга зарегистрировала сбой в работе сети;
  • 11 июля 2022, 16:11 (МСК) — сетевые инженеры приступили к диагностике и сбору информации;
  • 11 июля 2022, 16:15 (МСК) — сетевые инженеры приступили к восстановлению работы обоих маршрутизаторов публичной сети;
  • 11 июля 2022, 16:35 (МСК) — сетевые инженеры восстановили работу первого маршрутизатора. Работа публичной сети в локации AMS1 была восстановлена;
  • 11 июля 2022, 18:21 (МСК) — сетевые инженеры восстановили работу второго маршрутизатора. Резервирование публичной сети в локации AMS1 восстановилось.

Причины и принятые меры

DDoS-атака сама по себе не была причиной аварии. Автоматическая система защиты корректно применила ограничения для входящего трафика.

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

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

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

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

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

С уважением,
команда поддержки Servers.ru

Отчет по глобальным сетевым неполадкам, 21 октября 2020



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

Основной причиной инцидента послужил сбой у магистрального провайдера Lumen (в прошлом Level 3).

Общее время неполадок составило 2 часа 12 минут.

Хронология событий:
17:10 МСК — наша система мониторинга начала регистрировать неполадки в работе публичной сети, и мы сразу приступили к диагностике;
17:21 МСК — мы обнаружили, что сбой связан с автономной системой AS203 магистрального провайдера Lumen, который начал анонсировать часть наших сетей от своего имени (неумышленный BGP hijacking);
17:24 МСК — мы начали убирать анонсы наших сетей у провайдера Lumen во всех локациях;
17:30 МСК — инцидент эскалирован в техническую поддержку провайдера Lumen;
17:45 МСК — отключение анонсов сетей через провайдера Lumen не принесло желаемых результатов. Более ста наших сетей продолжали анонсироваться автономной системой AS203. Для снижения влияния сбоя мы начали разделять затрагиваемые сети на меньшие блоки и анонсировать маршруты с большей маской через других операторов связи, где это было возможно;
18:35 МСК — специалисты поддержки Lumen подтвердили наличие сбоя;
19:17 МСК — специалисты поддержки Lumen сообщили, что обнаружили причину сбоя и занимаются её устранением;
19:22 МСК — специалисты поддержки Lumen восстановили корректную работу сети со своей стороны. Работоспособность сети полностью восстановлена;
19:30 МСК — наши сетевые инженеры начали возвращать анонсирование сетей в провайдер связи Lumen;
20:00 МСК — мы восстановили все анонсы наших сетей в оператор связи Lumen.

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

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

Приносим извинения за неудобства, доставленные этим сбоем.

С уважением, команда поддержки Servers.ru

Перезагрузка облачных серверов для работы с IPv6 и GPN

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

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

Требуемые действия:
  • 1. Корректно завершить в ОС облачного сервера все необходимые сервисы
  • 2. Перейти в portal.servers.ru → выбрать «Облачный сервер» -> «Управление питанием» → «Перезагрузить»

Обратите внимание, что команды «reboot» из ОС облачного сервера недостаточно для применения обновлений. Необходим перезапуск именно средствами Portal или Compute API.

После перезапуска облачного сервера версия эмулятора должна измениться на 17.х.х. Проверить версию можно при помощи команды Linux:
dmidecode -t1 | grep -i version

В Windows должен измениться параметр реестра
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS -> SystemVersion


Если у вас появятся какие-либо вопросы, пожалуйста, обращайтесь.