
Вы удалили сервер. Что от вас осталось
Нажали «удалить». Или просто перестали платить, и хостер сам всё выключил. Списания прекратились, машина из панели пропала, вопрос закрыт.
Не закрыт. За одной кнопкой стоит несколько независимых процессов, и заканчиваются они в разное время. Виртуалка исчезает мгновенно, диск освобождается когда-то потом, ваш адрес уходит новому владельцу через полчаса, снапшот от марта продолжает лежать и тихо оплачиваться, а ключ, который валялся на этом сервере, работает до сих пор, потому что ему никто не сообщил о вашем решении.
Разберём по порядку: что происходит с данными физически, сколько времени они живут по договору, что переживает удаление и почему следующий владелец вашего адреса может месяцами получать письма, предназначенные вам.
Кому пригодится: если удаляли серверы и не задумывались, что там осталось; если планируете переезд; или если просто интересно, что вам самому досталось в наследство вместе с новым адресом.
Содержание
- Кнопка «удалить» запускает не одно действие
- Два пути к одному финалу
- Сколько на самом деле живут ваши данные
- «Удалить» и «стереть» делают разное
- Почему на SSD перезапись не работает
- Как это решают всерьёз: уничтожение ключа
- Что переживает удаление сервера
- Ваш адрес уходит следующему через полчаса
- Что досталось вам от предыдущего жильца
- Порядок действий перед удалением
- Частые ошибки
- Короткий итог
Кнопка «удалить» запускает не одно действие
Основная ошибка мышления тут вот какая. Вы видите одну кнопку и предполагаете за ней одно действие: было и не стало.
На деле за ней несколько отдельных процессов у разных подсистем, и у каждого свой срок:
- Виртуальная машина останавливается и удаляется из гипервизора. Быстро, обычно мгновенно.
- Дисковое пространство помечается свободным и возвращается в общий пул. Когда его перезапишут чужие данные, не знает никто, в том числе хостер.
- IP-адрес уходит в пул свободных и выдаётся кому-то ещё. Часто это происходит раньше, чем что-либо сделают с диском.
- Снапшоты и резервные копии живут отдельной жизнью, потому что это отдельные сущности со своей оплатой.
- Внутренние логи хостера про вашу активность хранятся по своему регламенту, который к удалению сервера отношения не имеет.
Пять процессов, пять разных таймеров. «Сервер удалён» описывает только первый из них, а звучит так, будто описывает все пять. На это и расчёт.
Два пути к одному финалу
Сценария два, и путают их постоянно.
Вы удаляете сами. Тут всё быстро и в целом честно: сказали удалить, машину удалили. Опасность в другом, и она полностью на вашей стороне: удаляя машину, вы не удаляете то, что она успела наплодить снаружи. К этому вернёмся отдельным разделом.
Вы перестали платить. Тут появляется лестница, и вот на ней людей и подстерегает неприятность:
- Просрочка. Списание не прошло, сервер работает, приходят напоминания.
- Приостановка. Машину выключают. Данные на месте, но вы к ним не подключитесь. Иногда за это время продолжает капать плата.
- Отведённый срок. Сколько-то дней всё лежит выключенным и ждёт оплаты.
- Удаление. Срок вышел, всё стирается, и с этого момента возврата нет.
Запомните эту разницу заранее: приостановка и удаление это два разных события с разным запасом времени. А сколько именно длится третий шаг, вы, скорее всего, не знаете. Проверять это в момент, когда карта уже не прошла, поздновато.
Сколько на самом деле живут ваши данные
Я прошёлся по договорам нескольких хостеров, чтобы посмотреть на разброс. Он оказался приличный.
Одна оговорка про формулировки: почти везде написано «услуга может быть прекращена», а не «будет». Это верхняя граница вашего запаса времени, а не обещание им воспользоваться.
| Хостер | Что написано в договоре |
|---|---|
| Servhost | приостановка сразу, полное удаление через 3 дня |
| Host4Geeks | приостановка через 3 дня после срока оплаты, полное удаление через 5 дней |
| Hostxpeed | приостановка через 3 дня, прекращение услуги через 7 |
| KnownHost | учётная запись переводится в неактивные при просрочке больше 5 дней |
| Namecheap | 3 дня отсрочки для VPS, прекращение возможно после 14 дней приостановки |
| RealHost | неоплаченный VPS хранится 2 недели, дальше удаляется полностью |
| Ace Hosts | приостановка сразу, данные лежат месяц, потом стираются |
Разброс от пяти дней до месяца. То есть у одного хостера вы уехали в отпуск, карта не прошла, и через пять дней от проекта ничего не осталось. У другого в той же ситуации есть четыре недели, чтобы заметить.
Отпуск, замечу, у обоих длится две недели.
Рейтинга хороших и плохих тут нет: короткий срок хранения не жадность, а экономия на месте, которое иначе занимают мёртвые виртуалки. Но знать свою цифру надо до того, как она понадобится, и искать её надо не в рекламе, а в пользовательском соглашении, в разделе про неоплату.
Второе, что стоит проверить там же: удаляются ли резервные копии вместе с услугой. У части хостеров прямо написано, что при прекращении услуги копии тоже стираются. Логично, но людей это регулярно застаёт врасплох, потому что бэкап воспринимается как страховка от всего, включая собственную забывчивость. От неоплаты он не страхует.
Для того чтобы намного быстрее получить эту информацию - вы можете обратится в поддержку хостинга, думаю на все ваши вопросы сможет ответить хостинг быстрее, чем вы сами найдете эту информацию.
«Удалить» и «стереть» делают разное
Переходим к физике, и тут начинается интересное.
Когда вы удаляете файл на своём компьютере, данные никуда не деваются: файловая система просто помечает место как свободное. Все это знают. Гораздо реже задумываются, что на уровне облака работает та же логика, только этажей больше.
Удаление виртуалки означает, что её диск возвращается в общее хранилище как свободное место. Данные в блоках физически остаются лежать, пока поверх них не запишут что-то другое. Когда это произойдёт, зависит от загрузки хранилища и не гарантируется никем.
Есть стандарт, который эти вещи разделяет, и на него удобно опираться, потому что он же лежит в основе большинства регламентов. Американский NIST SP 800-88 описывает три уровня очистки:
- Clear. Перезапись обычными командами. Спасает от восстановления бытовыми утилитами, от лаборатории не спасает.
- Purge. Серьёзные методы: аппаратная команда очистки, уничтожение ключа шифрования, размагничивание. После этого восстановление считается неосуществимым даже современными средствами.
- Destroy. Физическое уничтожение носителя: измельчение, сжигание, расплавление.
Так вот. Обычное удаление виртуалки не дотягивает даже до первого уровня. Оно вообще не про очистку, оно про освобождение места. Это не обман со стороны хостера, просто слово «удалить» в интерфейсе означает не то, что вам кажется.
Почему на SSD перезапись не работает
Хорошо, скажет читатель, значит надо перед удалением всё забить нулями. Совет из девяностых, и на жёстких дисках он работал.
На твердотельных накопителях он не работает, и вот почему.
У SSD между адресами, которые видит операционная система, и физическими ячейками памяти стоит переходный слой. Он существует потому, что ячейки изнашиваются от записи, и контроллер обязан размазывать нагрузку по всему объёму равномерно. Когда вы «перезаписываете» блок, контроллер не трогает старую ячейку. Он пишет в другую, свободную, и просто переставляет указатель. Старая ячейка со старыми данными остаётся лежать, пока до неё не дойдёт очередь на очистку.
Плюс у любого SSD есть резервная область, которой в адресах ОС вообще не существует. Дотянуться до неё обычными командами нельзя, а данные там оседают.
Это не теория. В работе, представленной на конференции FAST в 2011 году, исследователи проверили методы очистки эмпирически: вычищали накопитель, а потом снимали данные напрямую с чипов памяти. Выводы такие:
- Встроенные аппаратные команды очистки работают, но производители местами реализуют их неправильно.
- Перезапись всего видимого адресного пространства дважды обычно достаточна, но не всегда.
- Ни один способ затирания отдельного файла на SSD не работает.
Последний пункт стоит перечитать. Стереть один файл так, чтобы его нельзя было достать, на SSD нельзя в принципе. Можно вычистить накопитель целиком аппаратной командой, и на этом список заканчивается.
А теперь наложите это на облако. У вас нет аппаратного доступа к накопителю: диск виртуальный, физический носитель общий и лежит под чужим управлением. Все ваши попытки что-то «затереть» изнутри виртуалки происходят на два этажа выше реальных ячеек.
Как это решают всерьёз: уничтожение ключа
Хорошая новость есть, и она изящная.
Раз надёжно стереть данные тяжело, задачу переворачивают: данные шифруют при записи, а при удалении уничтожают ключ. Носитель остаётся забитым шифротекстом, но без ключа это шум. В классификации NIST такой приём относится к уровню Purge, то есть считается полноценной очисткой наравне с аппаратным стиранием.
Плюсы очевидны: мгновенно, не изнашивает ячейки, работает независимо от того, где физически разбросаны данные по накопителю.
Отсюда следует практический вывод, который мне кажется главным во всей статье. Если хотите контролировать удаление своих данных, шифруйте их своим ключом с самого начала. Тогда вопрос «а стёрли ли на самом деле» перестаёт вас волновать: вы уничтожаете ключ у себя, и дальше неважно, сколько ещё месяцев блоки пролежат в чужом хранилище.
Это единственный способ получить гарантию, которая не зависит от чужой добросовестности. Всё остальное упирается в доверие: вам говорят, что стёрли, проверить вы это не можете никак.
Оговорюсь про цену. Ключ, который лежит на том же сервере, ничего не решает: он уедет вместе со всем остальным. Настоящая схема требует, чтобы ключ вводился извне, а это означает, что сервер не поднимется сам после перезагрузки. Безопасность тут покупается за удобство, и решать, нужна ли она вам по такой цене, надо осознанно.
Что переживает удаление сервера
Раздел, ради которого статью стоило писать, потому что тут теряют больше всего.
Машины нет, а следующее живо:
Снапшоты и резервные копии. Отдельные объекты с отдельной оплатой. Удалили сервер, а снапшот от марта остался, и за него продолжают списывать. Заодно в нём лежит вся ваша тогдашняя конфигурация, включая то, что вы потом посчитали секретом.
Образы и шаблоны. То же самое: сделали свой образ, чтобы разворачивать копии, и он пережил все машины, созданные из него.
Ключи и токены, которые лежали на сервере. Вот это самое важное. SSH-ключ для доступа к репозиторию, токен облачного API, ключ для отправки почты, пароль от базы на другой машине. Удаление сервера не отзывает ни один из них. Они продолжают работать, потому что вторая сторона про ваше удаление ничего не знает. Если содержимое диска кто-то потом достанет, все эти доступы окажутся у него живыми.
Доступы, которые сервер получал наружу. Ключ развёртывания в репозитории, вебхук, подписка на уведомления, разрешение в чужом файрволе.
Записи DNS. Про них дальше отдельный разговор, потому что тут выходит хуже всего.
Логи у хостера. Кто подключался, откуда, когда, сколько трафика. Они относятся к вашей учётной записи, а не к машине, и хранятся по регламенту хостера.
Общее правило простое: сервер удаляется, а всё, что он успел выдать наружу, остаётся действительным. Отзывать это надо руками и заранее.
Ваш адрес уходит следующему через полчаса
Теперь самая недооценённая часть темы, и по ней, к счастью, есть нормальные исследования, а не догадки.
Ваш IP не уничтожается, он возвращается в пул и достаётся кому-то другому. Вопрос только в скорости. Исследователи развернули в одном из регионов крупного облака собственную наблюдательную сеть: больше трёх миллионов запусков серверов, около полутора миллионов уникальных адресов за 101 день, то есть примерно 56% всего доступного пула. Выяснилось, что адрес там может менять владельца каждые полчаса.
Что получает следующий жилец, если вы не прибрали за собой:
Ваш трафик. Если где-то остался DNS-запись, указывающая на этот адрес, всё, что по ней идёт, приезжает новому владельцу. Запросы приложений, вебхуки, служебные уведомления. Иногда с токенами внутри.
Возможность прикинуться вами. Домен указывает на адрес, адрес теперь чужой, значит по вашему имени отвечает посторонний.
Масштаб проблемы измерен. В другой работе собрали 130 миллионов доменов, указывающих на облачные адреса, и обнаружили, что больше 700 тысяч доменов ведут на адреса, которые уже свободны и доступны для захвата. Отдельное наблюдение на двенадцати облачных платформах зафиксировало почти 21 тысячу случаев, когда такой захват реально использовали для размещения вредоносного содержимого.
Семьсот тысяч доменов. Списать такое на отдельных ротозеев не выйдет, это системная привычка целой индустрии: сервер убирают, а запись про него забывают. Причём убирают обычно аккуратно, с подтверждением в диалоговом окне, чтобы уж точно ничего не пропало.
Отсюда правило, которое надо запомнить намертво: сначала убираете записи DNS, потом освобождаете адрес. Не наоборот. Между этими двумя действиями есть окно, и в облаке оно может измеряться минутами.
Нормальные регистраторы удаляют A записи за секунд 15.
Что досталось вам от предыдущего жильца
Симметричная половина той же истории, и о ней думают ещё реже.
Адрес, который вам выдали, не новый. У него была жизнь, и её последствия теперь ваши.
Репутация. Если предыдущий владелец рассылал спам или его сервер взломали, адрес мог уехать в чёрные списки. Ваша почта перестаёт доходить, а виноваты будете вы, потому что разбираться придётся вам. Про то, как из этого выбираться, у меня есть отдельная статья.
Вообще в подобных случаях можно обратиться в поддержку хостинга и вам просто дадут другой IP.
Чужой трафик. На ваш свежий сервер начинают приходить запросы, адресованные кому-то другому. Это ещё не атака, а остатки чужих настроек: где-то не почистили DNS, где-то в конфиге прописан адрес.
Тут стоит сказать прямо: приходящий на ваш адрес чужой трафик разумно считать чужими данными и не трогать его. Соблазн посмотреть, что там прилетает, понятен, но по ту сторону живые люди и их сведения, и правильная реакция это закрыть порт, а не изучать содержимое.
Внимание сканеров. Если предыдущий владелец наследил, адрес может уже стоять в чьих-то списках интересного. Первые попытки к вам придут быстрее обычного, а обычное там и так около двадцати минут.
Проверить наследство стоит в первый же день: репутацию адреса в списках и что вообще на него приходит. Если досталось плохое, нормальный хостер меняет адрес по запросу, и это самый простой выход.
Порядок действий перед удалением
Тут порядок важнее содержания, потому что половина проблем возникает именно из-за очерёдности.
- Заберите то, что нужно. Данные, конфиги, история. После удаления взять будет неоткуда, и период ожидания, если вы попали в сценарий с неоплатой, может оказаться в пять дней.
- Составьте список того, что этот сервер знал. Какие ключи на нём лежали, какие токены он использовал, в какие сервисы ходил, что ему было разрешено.
- Отзовите всё из этого списка. Ключи развёртывания, токены API, доступы к базам, вебхуки, разрешения в чужих файрволах. Именно отозвать, а не понадеяться, что оно умрёт вместе с машиной.
- Уберите записи DNS. До освобождения адреса, а не после.
- Удалите снапшоты, образы и копии явным образом. Проверьте счёт через месяц: если что-то забылось, оно там всплывёт.
- Только теперь удаляйте машину.
- Через месяц загляните в счёт ещё раз. Забытые объекты обнаруживаются именно так.
Пункты со второго по третий занимают больше всего времени и пропускаются чаще всего. Если вы за всё время существования сервера не вели список выданных ему доступов, восстанавливать его придётся по памяти, и что-нибудь вы обязательно забудете. Вывод на будущее скучный: такой список проще вести сразу, чем собирать в конце.
Где это держать
Одна практическая мысль, раз уж весь текст про сроки и адреса.
При выборе хостера стоит посмотреть ровно два пункта, и оба лежат не в рекламе, а в пользовательском соглашении: через сколько дней после неоплаты данные удаляются и что происходит с резервными копиями при прекращении услуги. Разброс, как видно из таблицы выше, от трех дней до месяца, и это разница между «успел заметить» и «не успел».
Третий пункт проверяется уже после подключения: какой адрес вам достался и не тянется ли за ним чужая история.
У меня для проектов serv.host (промокод promo22382), и логика выбора была примерно такая же: понятные условия по срокам и чистые адреса, чтобы не разбираться с чужим наследством в первый же день. Плюс живая поддержка, которая по запросу меняет адрес, если тот оказался с прошлым.
Частые ошибки
- Считать, что «удалено» значит «стёрто». Удаление освобождает место, очистка это другая операция, и по классификации NIST обычное удаление не дотягивает даже до низшего уровня.
- Забивать диск нулями перед удалением. На SSD это не работает так, как вы думаете: контроллер пишет в другие ячейки, а старые остаются. Отдельный файл на SSD затереть нельзя в принципе.
- Освобождать адрес раньше, чем убраны записи DNS. Ровно так и получаются те самые сотни тысяч доменов, указывающих в никуда.
- Думать, что ключи умирают вместе с сервером. Не умирают. Отзывать надо руками, и лучше до удаления.
- Забывать про снапшоты. Они переживают машину и продолжают оплачиваться.
- Полагаться на бэкап в ситуации с неоплатой. У части хостеров копии стираются вместе с услугой, и это прямо написано в договоре.
- Не знать своего срока хранения. Выяснять его в момент, когда карта не прошла, поздно.
- Изучать чужой трафик, прилетевший на ваш новый адрес. Это чужие данные. Закрыть, а не читать.
Короткий итог
- За кнопкой «удалить» стоит пять процессов с разными сроками: машина, диск, адрес, копии, логи хостера. Совпадают они только в вашем воображении.
- При неоплате есть лестница: просрочка, приостановка, срок ожидания, удаление. У разных хостеров этот срок отличается от пяти дней до месяца.
- Удаление это освобождение места, а не очистка. По классификации NIST существуют три уровня очистки, и обычное удаление виртуалки не относится ни к одному.
- На SSD перезапись работает не так, как ждут: контроллер пишет в другую ячейку, а старая остаётся. По исследованию FAST 2011, затереть отдельный файл на SSD не удаётся ни одним способом.
- Работающее решение это шифрование с уничтожением ключа. И единственная гарантия, не зависящая от чужой добросовестности, шифровать своим ключом с самого начала.
- Удаление сервера не отзывает ничего, что он выдал наружу: ключи, токены, вебхуки, доступы. Они живут дальше.
- Адрес уходит следующему быстро, в облаке он может менять владельца каждые полчаса. Больше 700 тысяч доменов сейчас указывают на уже освобождённые облачные адреса.
- Сначала DNS, потом освобождение адреса. Обратный порядок и создаёт эту статистику.
- Вам тоже достался чужой адрес со своей репутацией и чужим трафиком. Проверять стоит в первый день.
Общий смысл такой. Сервер это не коробка, которую можно выбросить целиком. Это узел, от которого за время жизни расходятся связи наружу: доступы, записи, копии, ссылки в чужих конфигах. Удаление обрывает сам узел и не трогает ни одну из связей. Убирать их приходится руками, и делать это надо до, а не после.
Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему
Сторонний мой проект: Zapret2UI.
ПОСТАВЬ ЗВЕЗДУ ПЖ
Источники
- NIST SP 800-88 - руководство по очистке носителей, уровни Clear, Purge, Destroy
- Reliably Erasing Data from Flash-Based Solid State Drives (FAST 2011)
- Measuring and Mitigating the Risk of IP Reuse on Public Clouds - исследование повторной выдачи адресов
- Cloudy with a Chance of Cyberattacks - про брошенные DNS-записи и захваты
- Разбор темы брошенных DNS-записей в блоге APNIC
Sehen Sie sich die übrigen Artikel der Wissensdatenbank an — die angrenzenden Themen sind dort ebenfalls erklärt.
