Pull to refresh

Comments 49

Вот бреда ради: а если ввести понятие допустимого объема изменения при автоматическом обновлении, а в случае превышения данного порога требовать подтверждение? Перед «заливкой» новой версии файла сравнивать N сегментов в старой и новой версиях, если количество схожих сегментов превысило Y, то заменяем старую версию новой, в противном случае требовать подтверждения. Защита от дураков простая, как камень на палке.
Прочитал свой комментарий и почему-то про Adinf вспомнил… Аж прослезился… Как же давно это было…
… единственный антивирус, который я использовал. И то, не для защиты, а потому что нравился безумно крутой способ работы и потрясающая скорость. Эх, досовские времена.
Помню, сам не только вспомнил прослезился но даже пришлось написать простенький аналог adinf, так как нужной функциональности в других не нашёл, а надо было срочно что-то делать с непонятно почему гибнущими файлами и дисками.
Заголовок утренних газет от 17 января: «Новый криптовымогатель, авторы которого вдохновились комментарием российского хакера elanc с известного сообщества криптоанархистов и анархоразработчиков Habrahabr, шифрует несколько случайных кусков файла, общим объемом до 5%, дабы обойти поведенческие защиты известных антивирусов».
Я вот одного не понимаю — почему это не использует ни один антивирус? Почему так сложно отследить вызов стандартных библиотек шифрования и выдавать предупреждения? Касперыч просит дофига денег, но НИЧЕГО абсолютно не гарантирует. Бизнес по-русски.
Очень легко сфолсить, например. Вы просто не представляете количество фидбека, которое можно огрести за блок казалось бы абсолютно неадекватного поведения ПО.
Как их ловить — все постоянно думают, уверен, и в каспере тоже. Кто найдет серебряную пулю, тот получит очень много бонусов во всех смыслах.
Только не бывать этому, боюсь. :(
Veeam Enterprise Manager ведь не будет работать без ввода сервера в домен?
Доменную аутентификацию так просто не прикрутить.
Вопрос был будет он работать без домена или нет.
Ответ — будет.
Что там у вас за сложности с доменной аутентификацией — непонятно.
Сложность в желании закрыть доступ к серверу администраторам домена, но оставив портал самообслуживания.
Доменные администраторы в администраторы Veeam Enterprise Manager попадают через группу локальных администраторов сервера, если у вас как-то ещё им права не выдаются на администрирование всех серверов подряд.
Включить кого надо с необходимыми ролями в настройках Veeam Enterprise Manager.
Не забыть кого-то Portal Administrator'ом сделать.
а BUILTIN\Administrators в настройках Veeam Enterprise Manager выкинуть совсем.
Тогда у членов группы BUILTIN\Administrators на сам сервер доступ останется — RDP и прочее — но именно в Veeam административные права отсохнут.
Администратору домена не составит труда повысить права на доменной машине.
Читайте внимательнее.
на сам сервер доступ останется но именно в Veeam административные права отсохнут.

Ничего повышать на машине ему и не нужно.

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

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

Бакапы должны быть append-only. Тогда их нельзя будет уничтожить шифрованием.

Это не поможет против вируса на той машине, к которой подключены носители с бекапом. Ну, если только не написать специальную файловую систему с водкой и охранницами
Носители типа CD-R. Туда мультисессией можно заменять, при желании, но все предыдущие сессии тоже доступны, вместе с их данными.
А переставлять их вручную?
А стоимость хранения?
Есть WORM кассеты и схожая фича у NASов, но это скорее для требований регуляторов по долговременному хранению.
Это был бы идеал. Но в данный момент, при текущем уровне беспечности абсолютного большинства пользователей — недостижимый.
Как пример — год назад я искал флешки с аппаратным выключателем записи. В Томске не оказалось, пришлось через Интернет заказывать и ждать!
хм. а можно пример флешки где аппапратный свич — аппаратный, а не програмный на уровне дров? (именно такие я видел исключительно, блин)
Я долго искал — выбрал Qumo ИНЬ и ЯНь.
Кстати, на Яндекс Маркете среди россыпей ма это единственная марка с аппаратным микриком.
UFO just landed and posted this here
Да, но есть и программный: http://www.bertold.org/sdtool/

во-2х, поскольку это как с флопиками, надо «закрыть» датчик, то где гарантия что когда ты втыкаешь в чей-то ридер там уже не закорочено/заклеено, чтобы игнорировать шторку защиты?

Я бы предпочел, чтоб он отключал write enable ножку внутри самого чипа карты памяти…
UFO just landed and posted this here
UFO just landed and posted this here
А что делать если мы не используем ни винды, ни проприетарного софта?
— Бэкап сервер должен сам вытягивать файлы с резервируемых машин.
— Бэкап сервер не доступен по сети со стороны резервируемых машин.
— вылизанный годами rsync позволяет создавать снимки бэкапируемых каталогов, место будут занимать только изменившиеся файлы.
— даже виндовые машины можно бэкапить, на винде можно запустить ssh, а rsync умеет работать через него.
— скрипт — в крон/systemd.timer
Всё.
Вот как раз такой широкоизвестный и не особо защищенный инструмент как rsync — запросто может быть шифровальщиками «накрыт»
Во-первых, не настолько широко, чтобы шифровальщики его использовали.
Во-вторых, каким образом они его используют? Доступа с резервируемых машин к бэкап серверу не должно быть ни на уровне сети (фильтрация портов, dmz), ни на уровне «приложения» (ключи аутентификации, закладки, и тп).
Поэтому, или уже расшифруйте ваше «запросто накрыт», может мы чего не знаем, или не говорите впустую.

А можно с этого места поподробнее? Просто, не могу понять, как можно запороть бэкап порчей rsync'а на стороне системы, которую бэкапят. У меня получаются варианты, что процесс бэкапа рушится и выдаётся предупреждение админу, либо идёт замена всех файлов, но в этом случае всегда можно взять предыдущую купию файлов.
Единственный вариант, как порушить бэкап, так это заразить систему, которая хранит бэкапы, но предыдущий комментатор это учёл и указал, что "Бэкап сервер не доступен по сети со стороны резервируемых машин."

Согласен на все 100%. Немного дополню из продакшена:
Бсервер на Linux.
На источниках данных шаринг правами RO.
bash скрипт, монтирует шаринги, забирает данные rsync на основе различия размера и времени модификации.
12 (4+4+3+1) внешних USB 3.0 дисков с luks.
Доступ к Бсервер только у админов по ssh-sftp/ключи.
После создания суточного бэкапа сервер выключается, будится биосом в нужный момент бэкапа.
Админ по потребности будит сервер через wol
Как я понимаю вариантов воздействия шифровальщика на систему резервного копирования два:
— автоматически заменяются рабочие копии файлов на зашифрованные
— используя дыру в системе бекапа шифровальщик внедряется в систему резервного копирования и портит там все напрямую.
Второй вариант возможен (один пример известен), но честно говоря маловероятен. Для его парирования нужно использовать две разных системы резервирования, а также периодически контролировать состояние бекапов.
Гораздо более вероятен первый вариант. Пройдемся по предлагаемым мерам защиты
— Имейте резервные копии, хранящиеся offline (без подключения к инфраструктуре). Если состояние резервных копий не контролируется, то хоть на луне хранить — испорченные копии попадут и в оффлайн
— Используйте для хранения бэкапов СХД с разными файловыми системами. Если система резервного копирования работает автоматически, то какая разница шифровальщику на какую ФС попадут испорченные данные?
— По возможности создавайте аппаратные снимки СХД резервных копий. Не понимаю, как это может помочь в предотвращении атак шифровальщиков
Пришла в голову такая мысль, а ведь большинство из этих вирусов шифруют файлы определенного типа, кто-то ориентировал вирус на фото, тобиш на рядового пользователя больше, кто-то на файлы бухгалтерии, бэкапы и так далее…
Довольно не плохо защищать файлы простым удалением расширения в имени файла, что бы вирус пропускал файл при поиске…
Этот метод будет годен ровно до тех пор, пока не станет популярным. То бишь он уже не годен.
Вроде бы на Ignite была занятная сессия от Полы Янушкевич по уменьшению вреда от малвари. Одним из советов было создание зацикленного симлинка в профиле, чтобы шифровальщик застрял на нём.
И этот метод будет годен ровно до тех пор, пока не станет популярным. То бишь он уже не годен.
Это догадка или есть анализ зловреда с обходом подобных трюков?
Ну вот сами подумайте. Способ годный, и начинает набирать популярность. Будучи автором зловреда в такой ситуации, вы бы сами не сделали обход этого метода? Технически то это возможно.
Он может иметь популярность у айтишников (которые не являются ЦА шифровальшиков), а обычные люди такой ерундой не занимаются. Плюс низкая культура разработки у авторов зловредов не позволяет отвлекаться на малополезные рюшечки.
Вы говорите о вирусе, основная ЦА которого — обычные пользователи, а решение предлагаете, нацеленное на айтишников. Определитесь.

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

Рюшечки остаются рюшечками, пока они не влияют на доход. Если зацикленную симлинку начнут по умолчанию создавать во всяких пиратских сборках винды (как один из твиков, например, в свое время это было отключение автозапуска на флешках), то оно перестанет быть рюшечкой, и даже автор с низкой культурой разработки позаботиться о фиксе.
Хорошая статья, полезная, особенно первый пункт о том что для бэкапа надо использовать отдельную учётку… так почему же тогда вы, разработчики не даёте использовать такую возможность в своём Veeam backup agent?

В агенте при бэкапе на сетевую шару можно указать отдельную учетку для доступа к ней. Главное не дать Windows запомнить пароль для шары (Windows предложит и нужно отказаться).

Sign up to leave a comment.