Хотелось бы узнать ваше мнение поможет или нет защититься от шифровальщика(интересует защита только файловой БД 1С).
Настроил архивацию БД(Cobian backup) на локальный и компьютер в сети(через общий доступ) архив изначально ZIP защищенный паролем, после создания архива у него удаляется расширение. Поможет ли это защитить БД?

(1) пусть получает доступ на чтение - не жалко

1С:Облачный архив

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

(0) ты кроме пароля и расширения ещё разбей на 100 частей =))

еще все документы можно хранить на шаре с shadow copy, чтобы все предыдущие версии хранились.

(0) Копируй бэкапы в неразмеченную область

не работать под админом. разрешать запуск приложений только из program files, запись туда пользователю запретить.

(7) по 1.44мб)))
(6) Попробую
(9) Чем это можно делать?

(9) !!!!! )))) это пять ))) я на флешке так файл прячу )

а не лазить с рабочего компа по порно сайтам и письма не открывать предлагали?

(13) Это слишко сложно

(11) truecrypt'ом создаешь скрытый раздел в неразмеченной области. батником монтируешь и копируешь

(13) А чем тогда на работе заниматься?

(11) надо быть современным Zip диски -100мб!!! =)
(9) diskpart

(15) Спасибо сейчас попробую

(15) нах когда есть битлукер и ефс?

+ монтируй отключай vhd

(19) Используешь сатанинские решения от m$ (

копировать на флеху/DVD уже предлагали?

как защитится от шифровальщиков?

1. внешний usb hdd и mountvol
2. webdav/ftp
3. linux

(15)А нафига трукрипт? Неужто системными средствами раздел уже создать нельзя?

(0)Не факт.
Чтобы защитил нужно сделать одно небольшое усовершенствование - на том компьютере в сети, куда копируешь БД, напиши простейший батник который будет перемещать бэкап записанный в общую папку в другое место, не расшаренное по сети.
И повесь этот батник в планировщик задач.

(12)Вот прям в неразмеченной области прячешь? Я вот не верю.

(26) если этот комп будет заражен один фиг побьет бэкапы. Тут либо программно защищать, например, разграничением прав, либо аппаратно, например закидывать бэкапы на съемные носители, или на запороленный ftp

(28) Что значит если этот комп будет заражен?
Для этого и копируют на другой компьютер.

(29) тот компьютер, на который копируют, имеет совершенную защиту?

(26)(28) как дети... нужно не только делать бекапы, но и проверять их на валиднось. а то будет полный диск мусора :)

(31) списибо копетан

(31) Речь была именно о том как делать бэкапы.
А не о том как их проверять.
Разумеется проверка нужна, причем проверка это далеко не единственное.
При нормальном бэкапе кроме собственно бэкапа нужно -
1)Грамотный мониторинг специалистом - толку от настроенного бэкапа если он через неделю перестанет работать из за каких-то неполадок?
2)Регулярная проверка качества бэкапов - ну это понятно.
3)Должен существовать четкий и подробный план аварийных действий, и развертывания бэкапа, причем желательно на бумаге, причем проверенный на практике.
Вот на этом кстати многие прокалываются - случилось что то и бэкап есть, а вот как его грамотно развернуть, каким софтом, и что для этого нужно никто точно не знает.

(33) Бэкапы надо делать в любом случае, но тема не о том.
Грамотный план архивирования хорошо реализуется на SQL, а SQL-ные базы шифровальщику не по зубам. Кстати, открытые файловые базы он тоже не тронул (вирус-шифровальщик Vault) Что могло грохнуть все файловые базы 1С? - в моем случае он "почистил" тестовый сервер. Основные рабочие базы на SQL - шифровальщику не по зубам. Вспомогательные файловые обычно тоже запущены под "Роботом" (служебный пользователь обмена данных) - тоже не по зубам.
Вывод - держите файловые базы постоянно открытыми, даже если они не ведут обменов с другими базами.

1С базы - хрен с ними, нужные из бэкапов восстановил, а вот с jpg-фотками что делать? Жена всю плешь съела...

(35) В Облака кидать. Китай как-то 36Тб раздавал.

(34) sql шифрование бэкапа вилами на воде, если делать шифрование бд, да круто но производительность ..

(36) Года 3 назад мелкософт с облака похерил все данные и вообще аккуант удалил, служба поддержки отечественная мямлила на отмазы уровня продовщицы киоска

Расшифровывать 1С базы большого смысла нет - им нет веры, а jpg-фотки - никто не пытался?

(0) >>>> у него удаляется расширение

Расширение, так то нужно только человеку. Программе, написанной правильно, побоку на твои ухищрения :)

(35) Удалить, начать все по новой :)

(38) Облака резервировать другими облаками...
Раз в год покупать новый накопитель взамен старого. На старый скидывать старые редко используемые данные...

(41) Забэкапить. Вдруг потом появятся процессоры и софт, которые за час (вместо 10 лет) тупым перебором найдут вариант расшифровки.

(39) Вы таки дома поймали сей зловред? Таки с таким же успехом мог навернуться Винт, ПК мог сгореть, Его могли украсть, Файлы могил удалить, те же дети :)

Все это мирское :)

(34)А почему вы считаете что грамотный план архивирования легче реализовать на SQL?
Я считаю что без разницы - одинаково легко бэкапяться как файловые так и скулевые базы.

(0)
У нас в облако архивы баз (запароленный естественно со сложным паролем) еженощно уходят.
Правда объем баз небольшой. В архиве все суммарно около 1 Гбайта.

(12) На SSD так не делай...

(35)В облака.
(38)И что такого? Какой шанс что одновременно навернется облако и твой комп с фотками?
(39)По идее это возможно и не так уж сложно.
Шифровальщик шифрует не весь файл, это очень долго и нафиг никому не нужно.
Обычно шифруется три небольших блока данных, в начале, середине и конце файла.
Для базы данных потеря даже небольшого куска критична, а для фотки это всего лишь потеря небольшого количества пикселов, не критично.
Но это для фоток в RAW формате. А вот для сжатых все хуже, там идет кодировка, и кодировочная таблица которая лежит в начале файла будет повреждена, и ты его уже не раскодируешь.
Поэтому храни в сыром виде, либо бэкапь в надежное место заголовки.

(46)А что такого в SSD? Почему нельзя?
И вообще это невозможно.

(48) Потому что если у тебя не что-то древнее типа XP, то ОС регулярно шлет ему команду TRIM, в которой передает диску неиспользуемые ей блоки (чтобы SSD их стер). Естественно, что неразмеченная область будет помечена как неиспользуемая, и SSD ее сотрет. А так - ничего невозможного в этом нет, просто открываешь диск на запись как устройство - и пишешь.

(49)Ну по порядку -
Во первых любой SSD будет затирать неразмеченную область и без всякой команды TRIM. Трим нужен и важен чтобы затирать удаленные файлы в размеченной области.
Поэтому неразмеченаня на SSD в любом случае будет затерта.

Во вторых - поясни пожалуйста как именно можно писать в неразмеченную область?
Я о таком не слышал, и на основе своих знаний считаю это невозможным.
Ты не путаешь это случайно с записью в несмонтированный раздел? Т.е раздел не имеющий буквы?

+(50) Под невозможностью записи в неразмеченный раздел, я понимаю запись штатными средствами.

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

(50) SSD - Диски.... У них есть ограничения... Их не стоит выключать на долго. Иначе рискуете за короткий срок потерять все данные :)

(52)Ограничения есть у всех.
Да SSD при длительном отключении от питания -месяцы, годы, способны терять данные. Но на практике никто собственно и не применяет их для длительного хранения информации.
Они как раз позиционируются как устройства для работы с горячими данными.

У HDD тоже куча своих ограничений.
В курсе что HDD не работают на большой высоте? Например в горах.

(53) Вроде как не все :) Слышал о герметичных моделях, заполняемых то ли азотом, то ли каким-то инертным газом.

(50) Диск работает на уровне ниже файловой системы. Поэтому для него неиспользуемым будет только тот блок, в который ни разу не писали после полного стирания. Поэтому их стирать не надо - они уже стерты (более того, SSD даже не выделяет под эти области место в памяти, и эту память использует для своих нужд). Команда же TRIM сообщает диску, какие блоки не нужны с точки зрения файловой системы, чтобы диск мог и эти области освободить для своих нужд.

(51) Все просто: открываешь физический диск как файл и пишешь. Куча дисковых редакторов такое делает.

(53) Горы горами, но речь идет о хранении таких фалов, как JPG. И других фото за всю жизнь :)
Человек тут задался вопросом, как восстановить данные, но и сохранить сеи архивы в длительностью жизнь, тоже не так просто :)

(55)
По поводу записи в физический диск - приведи пример.
Я знаю как штатными средствами работать с разделом который не примонтирован, т.е на диске создан раздел, но система его не видит. Это не проблема и делается очень просто по метке раздела.
А вот как записать на неразмеченное пространство? Раздела нет.
Т.е надо реализовать какую то ФС, и работать с диском на уровне посекторной записи. Если на диске вообще нет разделов, это в принципе возможно.
Но если это неразмеченная область на диске, другая область которого используется ОС это нереально, т.к будут конфликты, ибо надо согласовывать свои действия с ОС.


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

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

(58)Насколько я помню в дропбоксе доступ к версиям есть только в платной версии. Или ошибаюсь?

А вообще проще и логичнее использовать не синхронизатор типа дропбокса, а сервис хранения типа MEGA.
Да и беслатного места в MEGA как то побольше будет.

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

+(60) Несколько сложнее, но по тому же принципу можно и с физическим дополнительным диском работать при желании.

(60)В то время как диск примонтирован, шифровальщик вполне себе шифрует файлы на этом диске.
Проще уж без монтирования.

(62) Интересно, а credentials исключительно для текущего процесса как-то можно выставить? Т.е. монтирование в рамках процесса не подключает диск другим процессам. Ну или если через runas выполнить скрипт, будет ли хард виден текущему пользователю? Не проверял как-то :)

(0) Поднять сервер на какой-нибудь более другой ОС и после backup, сделанного стандартными средствами, средствами этой OS перетащить файл туда. Таким образом, шифровальщик не получит доступ к хранилищу backup'ов.

(63)Монтирование это понятие файловой системы.
Кто имеет право пользоваться файловой системой тот и увидит.
А доступ будет зависеть от прав, которые выставишь на точку монтирования.

Можно писать на диск и без монтирования. Хотя никто не запрещает это делать и шифровальщику.

на винде от шифровальщиков можно защититься только белым списком разрешением, т.е. "всё запретить, кроме"

(65) А, ну дык если выставить права на подключенный сетевой диск для другого пользователя (например, backup) и запускать скрипт резервного копирования через runas, то проблема какбе решена, не?

+(67) Шифровальщик, работая под текущим юзером, зайти на сетевой диск не сможет, а скрипт бэкапа - скока угодно.

(57) CreateFile("\\.\PhysicalDisk0", ...) - и пиши-читай что хочешь штатными ReadFile() и WriteFile().

(67)В основном да, но не на 100%

Т.е шифровальщик однозначно работает под каким то пользователем.
Если этот пользователь не имеет доступа к какому то месту, значит и шифровальщик не имеет.

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

(70) А как он повысит права, если юзер не знает пароля админа?

(69)PhysicalDisk0 - что это? И где его посмотреть?
Я знаю идентификатор тома (GUID) -
т.е вместо буквы диска пишем в батнике адрес  \\?\Volume{в скобках указан GUID тома}\ и все работает.

А вот как на физический диск, можно поподробнее?

(71)Это сложно, но возможно - есть дыры в ОС которые могут эксплуатироваться для повышения прав. Их закрывают обновлениями безопасности, но не факт что они установлены.
Хотя надо сказать такое бывает довольно редко.
У шифровальщиков не слышал чтобы были такие фишки.
А вообще у вирусов это бывает.

Я у себя всегда делаю бэкапы под спец учеткой.
Т.е не под админом, а под бэкап юзером.
Причем отбираю права на бэкапы у админа.

Это не 100% гарантия, но шанс ничтожный.

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

Т.е даже если шифровальщик получит доступ к шаре -  бэкапы там не хранятся.

(72) Вместо 0 можно подставить число от 0 до 15. Нумерация зависит от порядка подключения дисков к системе. Соответственно, определить какой именно тебе диск нужен можно только по его свойствам типа размера.

РИБ!

(76)Хм. А где об этом можно почитать?
И как это будет выглядеть?
"CreateFile("\\.\PhysicalDisk0", ...)"
Тут меня смущает строчка "CreateFile"
Файл это объект файловой системы, как можно создать файл вне файловой системы?
Т.е написали вы CreateFile, указали диск, а кто будет решать в какой именно сектор диска будет записана информация?
Как потом обращаться к этому файлу?
Или эта процедура вам вернет адреса секторов диска?

Я не спец в этой области, но насколько я понял CreateFile работает с файловой системой, а не с диском.
Это вообще какой язык? Откуда строчка?

(59) У меня бесплатная версия, доступ к версиям файлов есть. Фишка как раз не в том что это хранилище(в котором шифровальщик может тоже нагадить) а в том что это хранилище с версиями и можно откатиться к нужной в любой момент.

(80)А в хранилище то как шифровальщик может нагадить?
Заразить сервера хранилища и нагадить?

А кто в курсе по какому принципу шифровальщик ищет файлы? Если не по расширению, он что открывает все в подряд файлы даже системные?

(82) и если например это будет архив с паролем он сможет получить к нему доступ?

(78) https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

(82) http://bfy.tw/25MM

(83) Шифровальщику то какая разница, что шифровать? Ну архив с паролем, он его и открывать не будет.

(81) Не надо никого заражать. Если пользователь имеет доступ к архивам - ну и под его правами запустится шифровальщик.

Я создал и продаю защиту от шифровальщиков. Успешно.

(44) В SQL-ных базах это штатно предусмотрено. Еще в SQL200 у меня все на автомате было: ночные полные бекапы всех рабочих баз, перенос их на сервер бекапов, а также на мой тестовый сервер, и разворачивание на нем. Утром прихожу, у меня все свежие копии баз есть, в них дальнейшие доработки делаю, "разбор полетов" там же...

(84) Physical Disks and Volumes Direct access to the disk or to a volume is restricted.

(88) Если для пробы пару фоток пришлю, расшифруешь?

все не читал. переводить на sql не предлагали?

(0) Есть такая штука NAS - по сути коробка с 1 или 2 винтами, есть модели с поддержкой скриптов, ОС - что-то типа linux, могут как подключаться к шарам винды, так и расшаривать свои папки. Вирусов под них ПОКА (!!!) тупо нет.
Покупаешь сию штуку (где-то в районе 50-70$), архивирование у тебя настроено, а NAS просто заберёт во внутренние папки готовый файл, только нужно настроить, что-бы он хранил не одну а, например, 12 последовательных копий.
Достать можно только через доступ через спец ПО или ВЕБ-интерфейс, что вирусы пока не могут делать.

Если есть старый комп и желание, то можешь сгородить NAS на основе Linux.

(90) Во-первых, в неразмеченную область писать можно. Во-вторых, если заблокировать том - можно писать и в размеченную область.

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

(89) А в файловых базах точно так же все штатно предусмотрено.
SQL база хранится на  sql сервере поэтому штатные механизмы бэкапа, это механизмы которые предоставляет sql сервер.

Файловая база храниться в файловой системе, поэтому штатные механизмы бэкапа, это механизмы которые предоставляет файловая система или операционная система.
Тут вам и VSS  и wbadmin и повершелл с командной строкой позволяющий всем этим управлять.

(92)Чем поможет? И как ты вордовские документы в sql переведешь?

(94)Ладно не буду спорить.
Но если писать напрямую, то это надо лепить что то вроде подобия файловой системы. Так?
Т.е надо где то хранить адреса секторов диска на которых расположены данные.

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

(97) речь про файловую базу идет, есличо

сотка

(99) Ну да, проглядел что речь конкретно про файловую базу 1с.
Хорошо.
Тогда чем поможет перевод файловой в скуль? Что шифровщику труднее шифровать скульную базу?

(95) Видимо имеется ввиду клиент, установленный на зараженной машине. Естественно зашифрованные файлы засинхронизируются в облаке. Или нет?

(102)Я как раз и говорю что надо пользоваться не синхронизаторами типа дропбокса, а хранилищами типа MEGA.
Т.е сделали бэкап запустили консольный клиент из батника, который закинет файлы в облако.
Шифровальщик может сделать и изменить что угодно на вашем компьютере, но что он сделает с файлами в облаке?
Это же надо залогиниться в облаке, и используя API удалить файлы. Где он возьмет логин и пароль от облака, и откуда он узнает какое именно облако используется, и какое именно АPI использовать?