Comments 72
Поправьте пожалуйста в самом начале статьи 2 ГБ)
Очень сумбурно. Подключение по рдп было с этого компа на другой, или с другого на этот? Как подключение влияет на удаление файлов? Там было пересечение по именам дисков, или антивирус, или что-то другое?
Не RDP, а RDM это "немного" разные вещи. И самую мякотку расследования про РДМ нам не рассказали.
я по роду профессии (программист 1с) работаю с множеством удаленных рабочих столов клиентов (порядка 10). Какой именно из них занимается порчей файлов и почему непонятно - может это вирус, может сбой скрипта. Почему он удаляет только на дисках U, Y, а не трогает C:, D:, Q:, тоже неясно. Но вывод такой - не используйте расшаривание локальных дисков. Даже если файлы не удалят, их могут скопировать.
То есть файлы удалялись при подключении к удаленному рабочему столу, потому что я подключался с доступными для записи локальными дисками!
Непонятно, почему RDP в принципе решил массово удалять файлы. Кто его надоумил это делать? Ведь надо решать проблему в корне а не лечить симптомы ограничением доступов в R/O.
Потому что человек не использует РДП, а использует РДМ. Море подробностей про диски, тоталкомандеры и прочее. И ноль информации про РДМ. А проблема пришла оттуда. Ждем сериал "Как я спасал данные".
случайно задел ногой HDD, копирование прекратилось
Вот здесь я поржал. Спасибо.
Выводы
... 8.
Как бы... очевидно, нет?
U: ёмкостью 2 Гб
Выше уже написали. На снимке явно 2 ТБ.
Полные архивы надо делать хотя бы раз в месяц
Раз в месяц? Рисковать месячным объемом работы, который в иной месяц стоит пары лет? Мсье еще не слышал про синхронизацию, которую стоит выполнять раз в день, а то и чаще?
я имел ввиду полные архивы. Ежедневные архивы у меня тоже были, включая синхронизацию на яндекс. Тут они мне помогли. Против шифровальщиков бы не помогли. В поисках инструмента для надежного бэкапа сейчас.
Синхронизация - это и есть полный архив по состоянию на время синхронизации.
да, но это ненадежно. если шифровальщик зашфирует файлы, они окажутся на Яндекс-диске аккурат зашифрованными. Яндекс-диск версии поддерживать не умеет.
Нужна какая-то сторонняя утилита.
Шифровальщик - отдельно, синхронизация отдельно. Но если и совместить их, то поврежденными окажутся лишь файлы тех времен, когда завелся зловред, а не весь месячный архив.
это да. но если полный архив я делаю раз в месяц, а синхронизацию ежедневно, можно потерять месячную работу.
поставь duplicati и синхронизируй хоть каждый час, он будет передавать в облако только изменения и очень быстро.
В Обновляторе неплохо сделано. Только я думаю, для каждого файла должна быть ежедневная, еженедельная, ежемесячная версия.
или onedrive например, в котором есть версии :)
В бесплатной версии 30 дней у YD. И в приложении и в веб интерфейсе. В платной 90 дней.
А синхронизация в ядиске и т.п. ведётся по факту изменения файла. Так что после шифрования файл сразу и синхронизируется.
Я много лет использую вот это. https://duplicati.com/download - полет нормальный. Я кидаю на onedrive - просто потому что 5 Тб ни у кого больше за такие деньги не купишь, но он понимает кучу облаков и серверов для хранения бэкапов. Восстанавливается без проблем, проверял в деле :)
а принцип какой?
В каком смысле "какой принцип"? Запускаешь агента, он складывает шифрованные архивы выбранных папок в облако с заданными интервалами, понимает windows shadow copy чтобы открытые файлы забэкапить, делает инкрементальный архив, чтобы место использовать экономно. Агентом же восстанавливаешь из бэкапа, когда надо. Хранит версии, сколько укажешь.
т.е. если я шифровальщиком раз в 10 минут буду перезаписывать файл, этим я надорву возможности этой схемы?
Шифровальщик не переписывает раз в десять минут файл. Он отработал и удалился - чтобы вы его не поймали и не вытрясли из него ключ шифрования.
А если вы укажете хранить копию год - она будет храниться год. И даже если вы каждые десять минут меняете файл и загружаете его в хранилище, у вас будет просто очень много копий этого файла.
особо зловредный шифровальщик после себя создаст версию, которая не содержит ключа, но будет перезаписывать файлы раз в минуту, чтобы исчерпать хранилище.
Шифровальщик так не делает. Так может сделать человек, который хочет вам напакостить. Шифровальщик же просто зашифрует всё, до чего дотянется и самоуничтожится, оставив вам записку с координатами кошелька. Всё остальное ему не нужно. Ибо он работает на потоке - потому должен быть простым, быстрым и надёжным.
ну мы же не можем списывать со счетов вирусы-дестройеры?
Можем. Да, всегда можно придумать подход, который положит вашу систему бэкапа. Но надо ещё думать, как он с массовостью сочетается. Нахрена "дестроеру" каждые 10 минут что-то шифровать? Это бесполезно для его целей. Просто забил диск нулями и всё на этом. Большинство людей бэкапы не используется, а беспокоиться о самых хитрых смысла нет, слишком малый выхлоп относительно затраченных усилий.
Вот направленная атака - это другая история.
Так какова же Ужасная Причина удаления файлов? RDM сам файлы не удаляется, вообще-то.
Яндекс.диски и т.п. - это не бэкап, это синхронизация. Что у вас файлы остались в корзине - это повезло. Могла переполнится, могла очистится сама и т.п. А бэкап - это однонаправленное действия, из источника к цели. Обычно с поддержкой истории. Так что изменения в цели вам не сломают источник, а проблемы в источнике не приведут к уничтожению цели. Именно на это бэкап и нужен.
Вебдав на яндексе кривой, лучше синхронизацию через rclone настройте. Ну или подключение диска через него же, если вам именно "сетевой диск" интересен.
Не надо вертикально диски ставить. Ненадёжно это. Даже если не зацепите, он сам упасть может.
Причина удаления файлов - то что какая-то программа на сервере случайно или намеренно очищала диски U:, Y: и т.п., Q: не тронула, например. Может это сбой скрипта, может злонамеренная программа.
Т.к. диски в RDP были доступны, то она могла их чистить.
Программа работала именно в вашем сеансе, а не просто "на сервере". Так что смотрите, что у вас там в автозагрузке и логонскриптах.
нет, она работала на сервере, а не локально. Выполнялась в процессе Free Desktop Manager.
Она работала на сервере в вашем сеансе. Потому что пользовательские диски подключаются только в вашем сеансе, а не всем процессам на сервере.
Верно, она работала в моем сеансе на сервере RDP, там была какая-то штука, которая чистила подключенный диск. Т.е. не на моем компьютере, а именно на RDP
Я именно это и пишу. Это был процесс в вашем сеансе, а не системная служба. То есть вы можете его там отловить в своей автозагрузке или логонскрипте и посмотреть, что это такое.
проблема в том, что не повторяется. Я сделал один диск Z: для обмена
много там не хранил, типа как буфер.
И один раз, да. У меня этот диск очистился.
Причем так что аж сам пропал, потому что был сделан через Subs
Но потом я его подключил заново и больше удаление на диске Z не ловил.
Полет нормальный. Не знаю, что там чистило подключаемые диски и почему перестало.
Но выводы сделал - подключаю только диск Z:
Вот поэтому то я ВЕЗДЕ отказался от маппинга сетевых дисков по буквам. Только ссылка на ресурс. И пока, насколько я вижу, шифровальщики не парсят ярлыки на рабочем столе в поисках сетевых ресурсов.
WebDAV у Яндекса - организован своеобразно. Повторные эксперименты провожу один-два раза в год, то с одним, до с другим WebDAV-клиентом, на разных ПК. Последние 5-7 лет результат один и тот же: отправка на Яндекс Диск по этому протоколу работает очень медленно - десятки килобайт в секунду, практическое применение невозможно. А вот загрузка из Яндекс Диск - вполне терпимо - несколько мегабайт в секунду. В последнее время использую Good Sync - можно настроить несколько WebDAV-подключений чтобы выкачивать данные из отдельных "левых" папок в разных ЯД (разных аккаунтов), записывать можно в любые "правые" папки, сопоставленные по отдельности под каждую "левую" папку. "Правые" папки могут располагаться где угодно - на подключенных носителях или на сетевых ресурсах.
Можно запустить одновременное выкачивание по нескольким таким подключениям. Скорость снижается, но не критично. Всё это - односторонняя синхронизация, поэтому потом выполняется бекап на локальных ресурсах.
Програмист 1С - этим всё сказано. Когда Вы научитесь нормальным решениям backup ? 3-2-1, rto rpo, что мешало бекапить например в тот же яндекс в s3 ? Где комплексный подход к хранению ? Информация может "пропасть" и со смертью дисков и с шифровальщиками. Нужен комплексный подход.
у S3 есть недостатки в виде накопления потерянных очередей. Я об этом тоже писал на хабре, поищите.
Ubuntu 22
При установке ставлю галрчку Nextcloud.
Личное облако 2 ТБ.
VeeamBackup делает бэкап.
Доступ из интернета и домашнего пк.
0 проблем.
0 проблем
Это пока.
Очень интересно. Опишите подробнее пожалуйста.
что именно?
Я вот про это спрашивал
Потеря и восстановление данных 8 августа 2025 из-за беспечности в безопасности