По мотивам сбоя СДЭК

Простите , а вы с кем разговариваете ?

ну если импользовать серверы на винде, то да, геморроя не оберёшься

Размещено через приложение ЯПлакалъ

А как он под пользователем смог отключить антивир?

При чём тут контроллер домена, я хз но да ладно. Я вижу тупость и жадность руководства CDEK либо саботаж со стороны IT инфраструктуры. Как можно было зашифровать бэкапы? они что, сука, хранились в папке с общим доступом? Для такой организации как CDEK резервирование должно быть в реальном времени, чтобы в случае чего, откатиться можно было в течении 15 минут. И это не супер дорого или убер сложно. Даже если предположить что база данных выросла до неэпического размера, ну пусть это будет полтора часа. Я когда новость прочитал, я сначала не поверил. Это просто верх распиздяйства и похуизма.
Ладно... допустим вы не хотите тратиться на IT в плане держать штат и закупать сервера, так возьмите облако в ЦОД. Они там за вас будут каждый час делать резервирование и защищать ваши данные. Но нет, какой то эффективный менеджер решил сэкономить копеечку.

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

Защититься 100% от шифровальщика нельзя. Но возможно выстроить систему бэкапов так, чтобы всегда было из чего восстанавливаться.

1. - распределенное хранение бэкапов
2. - никакиого рдп к хранилищу бэкапов, а тем более под юзером с привилегиями.
3. - наличие оффлайн бэкапов (хотя бы на уровне отключаемого скриптом диска это минимум). В идеале и наличие холодного хранилища и наличие физически защищенной копии - т.к. диска в сейфе.
4. - Иметь S3 хранилку в облаке у хорошего провайдера с наиболее критичными бэкапами.

Такой подход позволит почти со 100% вероятностью восстановиться.
Ну и далее скорость восстановления будет зависеть от того что было в бэкапах. В идеале там должно быть ВСЕ критически важное - и копия VM КД и копии баз и копии конфигураций оборудования, а так же копии всех критически важных вирт. машин. Тогда процесс восстановления пройдет нормально.

Это сообщение отредактировал timonsterrr - 29.05.2024 - 13:20

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

А виной там всему было распиздяйство МТС в отношении бэкапов.

Это сообщение отредактировал timonsterrr - 29.05.2024 - 13:23

На линукс есть, но выдает ошибку при компиляции

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

Вообще в наше время в идеале лучше делать централизованно-древовидную систему. Представим себе некоторую сетевую корпорацию с кучей филиалов по городам.

1. Центральный сервер, на котором хранится база данных и кодовая база всего, что связано с интерфейсом (сайт, веб-морда и т.п.). Он может только принимать запросы и отвечать на них через API. С ним нельзя взаимодействовать напрямую. Всё через аутентификацию. К серверу НИКТО не должен подходить, кроме тех, кто непосредственно обслуживает сервер.

2. Серверы в городах, где есть филиалы. На них данные, связанные с конкретным городом. Ну и для лучшей производительности и распределения нагрузки реплика веб-морды и регионального поддомена сайта, если есть, которые обновляются с ЦС. Серверы взаимодействуют с ЦС. Опять-таки же с ними можно взаимодействовать только ограниченно. И доступа к ним не должен иметь НИКТО, кроме обслуживающего персонала.

3. Конечные терминалы. Они взаимодействуют с региональными серверами. На них НИЧЕГО не хранится. По сути они используют веб-морду серверов.

4. Центральный сервер ежедневно бэкапится. Притом на изолированный физический носитель.

ВСЁ (!!!) на "Линуксе"! Со всех терминалов удалено всё, кроме того, что нужно для работы. Установлены соответствующие ограничения на запуск программ.

Написать вирус под такую систему - уже непростая задачка, ибо Линукс. Ну попадёт такой вирус на терминал (с какого-нибудь вложения в письме, например). Дальше что? Напрямую он не сможет изменить данные на серверах, потому что через API. Да, можно зашифровать данные через API. Но тут можно сделать простую систему оповещения, которая будет поднимать тревогу при аномально высоком количестве запросов на изменение данных.

Ну как бы план хорош. Но весь цимес в том что в бэкапе могут находится уже зашифрованые данные трехмесячной давности. Пока шифрует шифровальщик обычно сидит тихо предоставляя все данные в расшифрованом виде. Может сидеть тихо достаточно долго. А потом "зравстуйте! Вы приехали".

Да че так "сложно" то )) всё сносим, ставим заново "Вдруг кому пригодится в будущем" )))

Я с Вами полностью согласен. Облако не панацея, но то что было у них, это полный абзац. Ну и как Вы опять же заметили, в случае с 1С, опять проблема в распиздяйстве.

Пиши пост, почитаем

Размещено через приложение ЯПлакалъ

Внуку через три года стукнет 5, надо не забыть будет спросить его, что такое "сейв"

Размещено через приложение ЯПлакалъ

Хорошая у вас корпоративная сетка. Надежная. У меня мaнегер может только обеденное меню в буфете посмотреть а не антивири оключать.

ТС, Что ты сделаешь в данном случае? Да у меня были холодные бекапы на съемном диске. Сеть поднял за 5 часов. Телефонию делали люди пару недель. Гребанные электрики.

111

222

333

444

Какой прелестный мамкин сисадмин писал старт топика :)

В более-менее нормальных компаниях, где переживают о сохранности данных чуть посильнее - все бэкапы существуют ПОЛНОСТЬЮ изолированно от основных доменов/деревьев доменов. Вырезанная среда. Если совсем по-нормальному - подключенная через изолированную сетевую инфраструктуру (да-да, в том числе и для этого у нормальных серваков сетевых адаптеров "пучок", а не один).

Структура бэкап-серверов полностью изолирована по подключениям. То есть вообще "невидима" для основного домена (файрволы или level3 - это уже вкусовщина).

И когда шифровальщик грохает "вообще всё" (хотя я плохо представляю как можно рабочий PDC грохнуть до состояния отказа, но допустим) - просто стопается вся инфраструктура, поднимаются образы сред виртуализации (заботливо сохранённые заранее), вкатывается сценарий восстановления последнего полного бэкапа, накатываются дифферанциалки и последовательно стартуются все хосты начиная с инфраструктурников и PDC и заканчивая хранилищами.

При лютых объёмах данных делается временная перекоммутация сети, в отдельных случаях - даже СХД.

А то что мамкин админ написал в старт-посте - это про какую-то купи-продайку, в которой приходящий 1С-ник, который ещё и типа сисадмин :)))

Компании уровня СДЭК работают несколько иначе (при условии, что там директор по IT "по знаниям", а не "по связям")

Ну а это глубина бэкапов и возможностей СХД.
Если не жмотиться.

Размещено через приложение ЯПлакалъ

Такого у меня не было.

Но вообще в текущей серверной стоит 4 уровня защиты по питанию, включая защиту от перегрузов, 2 "порошковых гранаты" и газовая система пожаротушения.

И да, холодные бэкапы в другом здании. Для них отдельное оптоволокно между зданиями.

Просто так. У нас подстанция была под серверной. Электрики там профилактику замутили. Вырубали на ночь. Включается ИБП. Кондей отрубился. Как я потом узнал, какой то мудак решил на скрутку медь/алюминий подключить кондей.

Было это еще до моего устройства на работу. Розетка была за шкафом снята и в ней сделали скрутку.

Дали ток. Кондей сказал нихе*ра себе и начал всё это дело охлаждать. Серваки работали часов 6 точно без охлаждения.

Загорелась скрутка. За шкафом. В шкафу пол-тонны инструкций от всего. Результат на фото.

Домен, я кстати успел вытянуть на новый BDC и через 5 минут сервак сдох.

Ну, восстановили вы всё, а завтра, если не устранить причину взлома, вам опять всё зашифруют.