Comments 20
Все это класно и правильно. Но относится скорее к системам хранения данных. Но 90% проблем с Петей у фирм попавших под удар не с серверами, точнее в основном не с ними. А с рабочими станциями. В 90% случаев на рабочие станции используют самые дешевые конфигурации, с не менее дешевой совместимой програмной средой. То есть Виндовс ХР. Т.е. СМБ вырубить конечно можно. Но сетевые ресурсы для этих рабочих станций перестанут быть доступными.
Я что хочу сказать. Уязвимости не появляются на пустом месте. Они следствия попыток сэкономить на IT.
Я что хочу сказать. Уязвимости не появляются на пустом месте. Они следствия попыток сэкономить на IT.
Основная масса в штуках, это конечно же компьютеры.
Но самые большие проблемы фирмам принесли именно вышедшие из строя сервера.
Поверьте я знаю о чем говорю, всю неделю без выходных и отдыха езжу по заказчикам ;)
Но самые большие проблемы фирмам принесли именно вышедшие из строя сервера.
Поверьте я знаю о чем говорю, всю неделю без выходных и отдыха езжу по заказчикам ;)
По поводу экономии, здесь 100% согласен. В постсоветских странах это мега фишка — экономия на ИТ, которая ВСЕГДА выливается боком.
Все привыкли ставить пиратское ПО из-за этого все привыкли что ИТ это дешево. Соответственно бюджетов на ИТ нормальных не выделяется и мы имеем то что имеем сейчас. Кстати из-за этого же недооценённые и сами ИТшники. Нужно объяснять бизнесу что ИТ — «это не дешево» и «это не то место, где можно экономить».
Все привыкли ставить пиратское ПО из-за этого все привыкли что ИТ это дешево. Соответственно бюджетов на ИТ нормальных не выделяется и мы имеем то что имеем сейчас. Кстати из-за этого же недооценённые и сами ИТшники. Нужно объяснять бизнесу что ИТ — «это не дешево» и «это не то место, где можно экономить».
стоит ли сходу блокировать RPC 135?
Отличная статья! Полностью согласен с тезисами. Без снепшотов действительно никуда. Рост объемов данных значительно опережает рост скорости резервного копирования и восстановления.
Я как-то писал статью, в которой разбирал основные проблемы современного резервного копирования. Главная из них, что время восстановления — это некая функция от объема данных и главная задача — разорвать это отношение. И сделать это можно только 2-мя способами:
Но с шифровальщиками все несколько сложнее. Если защищаться от него снепшотом — то нужно заложить как минимум 2х кратный объем на СХД (при полной перезаписи снепшот будет занимать объем, равный исходному тому)
Я как-то писал статью, в которой разбирал основные проблемы современного резервного копирования. Главная из них, что время восстановления — это некая функция от объема данных и главная задача — разорвать это отношение. И сделать это можно только 2-мя способами:
- Использовать быстро-производимые и -разворачиваемые копии (например, снепшоты)
- Использовать уже работающие копии с возможностью отката (Oracle Standby с FlashBack, различные CDP)
Но с шифровальщиками все несколько сложнее. Если защищаться от него снепшотом — то нужно заложить как минимум 2х кратный объем на СХД (при полной перезаписи снепшот будет занимать объем, равный исходному тому)
Действительно, если снять снеп, а потом все данные зашивруют, то по-сути данные увеличаться в два раза.
Но с технологией FabricPool снэпшоты смещаются с SSD накопителей на дешевое хранилище S3. Так что даже с вирусами-шифровальщиками снэпшоты не проблема. Так что с FabricPool снэпшоты сам доктор прописал.
Но с технологией FabricPool снэпшоты смещаются с SSD накопителей на дешевое хранилище S3. Так что даже с вирусами-шифровальщиками снэпшоты не проблема. Так что с FabricPool снэпшоты сам доктор прописал.
Спасибо за ссылку, на статью по резервному копированию, прочёл, очень хороший материал!
Как показывает практика, нужно защищаться:
Одно другого не отменяет, а дополняет, это видно даже по приведённым примерам в статье:
Так что мало того, что по-хорошему, нужно иметь
Чтобы быть готовым к тому, что если первый метод вовсе не сработает или восстановление по нему будет слишком долгое, тогда откатиться быстрее по второму методу и потом накатить изменения из логов по тому же первому методу (если получиться).
Как показывает практика, нужно защищаться:
- И программными средствами (типа Standby/ZDLRA/Continuous Data Protection/FlashBack)
- И снэпшотами (а по хорошему ещё нужно делать реплики этих снепшотов на резервную СХД, на которой из тонких клонов тестировать эти отреплицированные снэпшоты на восстанавливаемость).
Одно другого не отменяет, а дополняет, это видно даже по приведённым примерам в статье:
- Потому что, если просто иметь Standby то повреждённые данные могут отреплицироваться на запасную площадку.
- Полное восстановление из логов или фулл/инкрементов слишком долгое
- А сами по себе снэпшоты они теоретически могут быть подвержены скрытым повреждениям на СХД (хотя на практике с NetApp FAS такого не встречал, но теоретически может быть).
Так что мало того, что по-хорошему, нужно иметь
- Standby/ZDLRA/Continuous Data Protection/FlashBack
- так нужны ещё на этих же системах и снэпы
Чтобы быть готовым к тому, что если первый метод вовсе не сработает или восстановление по нему будет слишком долгое, тогда откатиться быстрее по второму методу и потом накатить изменения из логов по тому же первому методу (если получиться).
Презентация с анализом и примерами неудачных восстановлений после серии атак вируса Not Petya, Wanna Cry и других направленных атак на Украину за последние два года, в контексте возможностей систем NetApp.
http://bit.ly/NetApp-against-ransomware-slides
http://bit.ly/NetApp-against-ransomware-slides
А если речь не о системе для организации (где ценность и объём данных оправдывают достаточно дорогую систему защиты), а о домашнем применении — можете что-то посоветовать?
Мои мысли бродят в направлении линуксовой машинки + rsnapshot + (возможно) zfs. С запуском бэкапа со стороны этой машинки — чтобы рабочая машина вообще не имела к диску с бэкапами доступа на запись. Ну или ещё какими хитростями — лишь бы не давать доступа на запись к старым снепшотам.
Хотя предпочёл бы готовый NAS, умеющий всё нужное...
Посмотрите на NAS4Free с ZFS.
Там можно хранить файловую шару и даже запускать ОС с iSCSI.
При большем желании можно написать простую интеграцию для снятия снэпшота по каким-то событиям, к примеру выключение ОС.
Там можно хранить файловую шару и даже запускать ОС с iSCSI.
При большем желании можно написать простую интеграцию для снятия снэпшота по каким-то событиям, к примеру выключение ОС.
Спасибо.
Чтоб не искать (если помните) — на каком уровне nas4free "из коробки" обеспечивает функционал вида "снэпшоты неприкосновенны"? Запуск rsync server под chroot?
Не уверен что в NAS4free и ZFS есть WORM.
Не понял на счёт rsync. У ZFS/NAS4Free есть свой собственный механизм репликации на вторую NAS4free/ZFS.
Не понял на счёт rsync. У ZFS/NAS4Free есть свой собственный механизм репликации на вторую NAS4free/ZFS.
Ну, если из коробки нет — понятно, что можно настроить, по крайней мере, в достаточной степени (r/w доступ к папке, куда бэкапимся, r/o к снэпшотам.
Насчёт rsync — я про бэкап рабочей машины на nas в стиле http://www.mikerubel.org/computers/rsync_snapshots/ (на zfs получится лучше, конечно)
Не гонять же по сети все данные?
Ну можно и rsync«ом лить на ZFS, а на ZFS снимать снэпы, чтобы защитить от изменений снэпами.
А можно просто подключить iSCSI лун с NAS4Free и снимать снэп с этого луна прямо на хранилище, тогда по сети вообще ничего гонять rsync»ом не нужно, но тогда нужно как-до добиваться консистентности, если на этом луне будут жить не просто файлы.
Самый простой способ достичь консистентности это выкючить комп и снять снэпшот луна на ZFS.
А можно просто подключить iSCSI лун с NAS4Free и снимать снэп с этого луна прямо на хранилище, тогда по сети вообще ничего гонять rsync»ом не нужно, но тогда нужно как-до добиваться консистентности, если на этом луне будут жить не просто файлы.
Самый простой способ достичь консистентности это выкючить комп и снять снэпшот луна на ZFS.
Дома и на работе использую Freenas на HP Microserver G7.
Дома девайсы (ноут, пк и несколько HD-плееров) используют встроенный накопитель только для ос. Все данные на NAS через SMB. В ZFS создано 2 датасета:
— зеркало на WD Red, для документов, фото, хоумвидео (все что жалко потерять), включены снапшоты.
— страйп (2 диска последовательно) — для торрентов и что не жалко потерять.
На NAS также работает и Transmission.
В оффисе:
Кластерок из 3 нод. Одна нода полноценный сервер (12 ядер, 48 Гб ОЗУ), две обычных пк Core i5 16 Гб ОЗУ. В принципе все виртуальные машины помещаются с запасом на основном сервере, но если с ним нужно провести какие либо работы, вм распределяются (онлайн-миграция) по другим нодам.
Диски вм и домашние папки пользователен на хранятся на двух NAS. В каждом 2 SSD для дисков вм и 2 hdd для данных пользователей, бэкапов и реплик с других NAS.
Каждый NAS реплицирует свои данные хотя-бы на один другой. Что куда реплицировать можно настроить индивидуально. Например датасеты с образами вм реплицируются каждые пять минут между NASами в офисе, и раз в сутки еще и на нас дома (можно и чаще но особого смысла нет, это удаленный бэкап на случай украли\изъяли сервера).
Практически все настраивается из веб-интерфейса Freenas, только очистку от старых снапшотов делал через скрипт в croon. Freenas не удаляет автоматически снапшоты, получившиеся в процессе репликации.
Бюджетная и вполне удовлетворяющая мои потребности конфигурация. Дома Freenas уже года как 3 использую. На работе около года. Пока никаких проблем. Но Freenas надо обновлять осторожно, часто любят поломать, что раньше работало.
Дома девайсы (ноут, пк и несколько HD-плееров) используют встроенный накопитель только для ос. Все данные на NAS через SMB. В ZFS создано 2 датасета:
— зеркало на WD Red, для документов, фото, хоумвидео (все что жалко потерять), включены снапшоты.
— страйп (2 диска последовательно) — для торрентов и что не жалко потерять.
На NAS также работает и Transmission.
В оффисе:
Кластерок из 3 нод. Одна нода полноценный сервер (12 ядер, 48 Гб ОЗУ), две обычных пк Core i5 16 Гб ОЗУ. В принципе все виртуальные машины помещаются с запасом на основном сервере, но если с ним нужно провести какие либо работы, вм распределяются (онлайн-миграция) по другим нодам.
Диски вм и домашние папки пользователен на хранятся на двух NAS. В каждом 2 SSD для дисков вм и 2 hdd для данных пользователей, бэкапов и реплик с других NAS.
Каждый NAS реплицирует свои данные хотя-бы на один другой. Что куда реплицировать можно настроить индивидуально. Например датасеты с образами вм реплицируются каждые пять минут между NASами в офисе, и раз в сутки еще и на нас дома (можно и чаще но особого смысла нет, это удаленный бэкап на случай украли\изъяли сервера).
Практически все настраивается из веб-интерфейса Freenas, только очистку от старых снапшотов делал через скрипт в croon. Freenas не удаляет автоматически снапшоты, получившиеся в процессе репликации.
Бюджетная и вполне удовлетворяющая мои потребности конфигурация. Дома Freenas уже года как 3 использую. На работе около года. Пока никаких проблем. Но Freenas надо обновлять осторожно, часто любят поломать, что раньше работало.
Привилегии должен получать не только пользователь, а еще и приложение.
Например, .doc файлы должен изменять winword.exe и никто другой.
Например, .doc файлы должен изменять winword.exe и никто другой.
Sign up to leave a comment.
Как защитить корпоративное хранилище от вирусов-шифровальщиков снэпшотами