Если ты построил систему так, что любой еблан сможет уничтожить всë в ней под ноль открыв письмо с шифровальщиком на одном из компов в сети, то тебе в этой сфере нехуя ловить.
Размещено через приложение ЯПлакалъ
Такое я пропустить не мог, аж восстановил пароль забытый от yaplakal.
Какое "мать его за ногу" восстановление через бэкапы в виде файлов? 20 лет назад так делали, динозавры что ли в ИТ работают у вас там, вопрос за что зарплату получают тогда, если не развивают ИТ инфраструктуру и не переводят на современные решения??? Домен контроллеры поди 2003 стоят, да? Протокол SMBv1 не отключен???
Сейчас резервное копирование с восстановлением везде на уровне сервиса. Бэкапятся виртуальные машины на отдельное хранилище. Например на NAS. Логин и пароль система резервного копирования использует локальные NAS, сам NAS конечно в домен вводить не нужно, логин и пароль от сервисной учетки агента резервного копирования (сервисная учетка) шифруются в системе резервного копирования.
Восстанавливаются все критичные ИТ сервисы за 3-4 часа максимум и скорость восстановления зависит от скорости передачи данных, чтения и записи данных и все! Нет зависимости от умения ИТ специалиста установить заново ИТ сервис СУБД. Читаю я это все и немного в шоке.
Это сообщение отредактировал Nick413 - 29 мая 2024 в 01:12
Кому ты это расказываешь. Ходил туда устроиватся мне предлагали около 40 тыс за 14 часовой рабочий день, 5 дней в неделю. Ушел тогда с другой работы 60 тыс устроился на 80 тыс, и часов раза в 2 меньше. Там пиздец олени не пуганные сидят в руководстве. Так что сдох максим да и х с ним. Такие конторы должны пожраттся конкурентами.
Такое я пропустить не мог, аж восстановил пароль забытый от yaplakal.
Какое "мать его за ногу" восстановление через бэкапы с виде файлов? 20 лет назад так делали, динозавры что ли в ИТ работают у вас там, вопрос за что зарплату получают тогда, если не развивают ИТ инфраструктуру и не переводят на современные решения??? Домен контроллеры поди 2003 стоят, да? Протокол SMBv1 не отключен???
Сейчас резервное копирование с восстановлением везде на уровне сервиса. Бэкапятся виртуальные машины на отдельное хранилище. Например на NAS. Логин и пароль система резервного копирования использует локальные NAS, сам NAS конечно в домен вводить не нужно, логин и пароль от сервисной учетки агента резервного копирования (сервисная учетка) шифруются в системе резервного копирования.
Восстанавливаются все критичные ИТ сервисы за 3-4 часа максимум и скорость восстановления зависит от скорости передачи данных, чтения и записи данных и все! Нет зависимости от умения ИТ специалиста установить заново ИТ сервис СУБД. Читаю я это все и немного в шоке.
Да не получает там никто з/п, я с директором по телефону разговаривал там директор на 2 филиала на наш и на соседний город. Цирк с конями короче.
Если речь про шифровальщики, то он шифрует все компьютеры подряд: рабочие станции пользователей, контроллеры доменов, серверы резервного копирования, рядовые серверы, в общем всё, до чего сможет дотянуться по сети.
Извините. А как можно по сети дотянуться до сервера бэкапов? Ну или хотя бы до снэпшотов zfs?
вот это вообще пиздец... хотя я линуксоид, и в вендах ничо не понимаю, но хранить на системном диске базы, это выше моего понимания. хотя наверное никто не парится при установке софта "далее"-"далее" жамкают, посто же хуле, юзер-френдли ёбанаврот
Херота полнейшая в тексте, в винде как я помню с 2008 бекап работает четко и диски он скрывает от всех, шифровальщик бекапы не тронет это раз. В скл если открыть порт только 1433 насколько мне припоминается то хуй какой тибо шифровальщик проберется, для админки 3398 можно юзать, галки только на tcp/ip и QoS. И всё. Кстате скл бекапит в папки которым безопасность настраивает от экземпляра, так что даже в файловые бекапы шифровальшик не тронет.
Вы сначала почитайте технологию внедрения и распространения шифровальщика mimic, а уже потом пишите такие ламерские комменты. Над этим целая группа в Турции работала, спецом ориентирована была на сервера SQL корпораций. Шифрует всё подряд, у него в теле лежит список масок шифруемого, там и сами базы, и бэкапы, и скрипты , и 1С-ные базы , и виртуальные машины, в-общем всё, что есть . Технология развертывания, тоже продуманная. Вначале, вирус определяет все цели, подсчитывает объем будущего шифрования ( видимо, есть алгоритм подсчета лимита времени атаки), потом формирует файл-шифровщик и отправляет на все цели. Попав, отключает все сервисы, безопасность, теневые копии, скрывает свой процесс и начинает шифрование. После шифрования , самоуничтожается. Атака на сервера корпорации Ткачева, думаю, проведена тем же mimic-ом. У Касперского, нет ни расшифровщика, ни средства обнаружения клонов mimic-a. На сайте Каспера, советуют . только хранить зашифрованные, вдруг сольется алгоритм криптования ( такое было)
Это сообщение отредактировал Citizen72 - 29 мая 2024 в 01:24
Из всего текста я понял только, что тс работал в крупной компании. Всё остальное на каком то зашифрованном языке. Наверное в текст шифровальшик пробрался.
Вначале, вирус определяет все цели, подсчитывает объем будущего шифрования ( видимо, есть алгоритм подсчета лимита времени атаки), потом формирует файл-шифровщик и отправляет на все цели. Попав, отключает все сервисы, безопасность, теневые копии, скрывает свой процесс и начинает шифрование. После шифрования , самоуничтожается.
А потом мы поднимаем образ ВМ из бэкапа суточного, а БД из снэпшота 15-минутной давности и продолжаем работать.
Вначале, вирус определяет все цели, подсчитывает объем будущего шифрования ( видимо, есть алгоритм подсчета лимита времени атаки), потом формирует файл-шифровщик и отправляет на все цели. Попав, отключает все сервисы, безопасность, теневые копии, скрывает свой процесс и начинает шифрование. После шифрования , самоуничтожается.
А потом мы поднимаем образ ВМ из бэкапа суточного, а БД из снэпшота 15-минутной давности и продолжаем работать.
"и заменяем системные базы старыми" - так а если они то и зашифрованы, и бэкап тоже? Проблема же не в домене и не пользователях. Проблема в посылках, оплатах и статусах документов... Там же вся попаболь в том, что база и бэкапы зашифрованы....
На Trendmicro, почитайте обзор, там все схемы разложены. Это промышленный уровень атак, не домашние заготовки
Всё утыкается в скомпрометированные учётные данные в итоге. Но это уже человеческий фактор.
Всё, всегда, упирается в расковыривании доступа. Если, изначально, на 100% обезопаситься от появления вируса в системе, можно половину мероприятий по безопасности, сразу исключить. Но, пока , нет такого. Потому что , шифровальщик - это не вирус, а такая же программа, как любое другое приложение
"и заменяем системные базы старыми" - так а если они то и зашифрованы, и бэкап тоже? Проблема же не в домене и не пользователях. Проблема в посылках, оплатах и статусах документов... Там же вся попаболь в том, что база и бэкапы зашифрованы....
тут намекали на то, что помимо бэкапа баз, ежедневно создаются копии виртуальных машин. Тогда, при условии целостности копии ВМ, из нее подымается весь виртуальный сервер. Но, это - совершенно другие объемы резервирования и не майкрософтовая система ВМ. Всё реально и осуществимо, при иных затратах. Не у всех - такие бюджеты
Если речь про шифровальщики, то он шифрует все компьютеры подряд: рабочие станции пользователей, контроллеры доменов, серверы резервного копирования, рядовые серверы, в общем всё, до чего сможет дотянуться по сети.
Вот если вот то что преречислено случилось, значит админ был совсем долбоеб, что сказать то? Ведь доступ на выполнение этих действий у вируса появился не только лишь сам, а в результате тупизны админа или да?
Это сообщение отредактировал anikifya - 29 мая 2024 в 08:53
Прочитал про падение серверов СДЭК и прямо до мелочей вспомнил, как почти 7 лет назад принимал участие в устранении последствий вируса-шифровальщика.
7 лет назад я работал в крупной компании, и так как за два года до события я работал там же администратором баз данных, то меня тоже пригласили помогать в процессе поднятия серверов БД.
Всем, кто смеётся над рукожопостью IT-шников и отсутствию бэкапов, хотел бы рассказать как это выглядит в реале.
Если речь про шифровальщики, то он шифрует все компьютеры подряд: рабочие станции пользователей, контроллеры доменов, серверы резервного копирования, рядовые серверы, в общем всё, до чего сможет дотянуться по сети.
Прежде чем что-либо восстанавливать нужно найти выживший контроллер домена, если такого нет и нет бэкапа, то придётся строить инфраструктуру с нуля. Контроллер домена - это такой главный сервер в инфраструктуре, в котором содержится база данных всех пользователей, компьютеров, серверов и т.д. В нашем случае нам повезло и у нас такие нашлись. Параллельно начали поднимать серверы резервного копирования, по сути нужно взять и установить всё с нуля и подцепить к нему базу бэкапов.
Ну и после поднятия началась планомерная работа по восстановлению наиболее критичных систем.
Пока сисадмины возились с контроллерами я выработал схему восстановления серверов БД не прибегая к бэкапам. Повезло в том, что вирус не тронул файлы БД, а шифровал только офисные файлы, текстовые и системные каталоги Windows.
Процесс выглядел вот таким образом: 1. С диска c: копируются все файлы системных БД СУБД MSSQL(master, model, msdb и mssqlsystemresource) хоть на usb-флешку, т.к. они имеют небольшой размер. Если рабочие базы лежат на системном диске, то и их тоже. Кроме того можно посмотреть каталог C:\Program Files\Microsoft SQL Server\{version}\Setup Bootstrap\Update Cache, чтобы понимать какие обновления были установлены ранее. 2. Форматируется системный раздел и заново ставится ОС. 3. Заводим сервер в домен. 4. Устанавливаем SQL Server и все обновления, которые были на сервере до этого. 5. Останавливаем службы SQL и заменяем системные базы старыми(новенькие можно куда-нибудь скопировать на всякий случай, вдруг что-то пойдёт не так). 6. Запускаем SQL Server и проверяем получилось или нет.
В процессе установки ОС у подключенных дисков могут стать несколько иными буквы дисков, но в принципе при подключении старой базы master и в логах SQL Server можно увидеть нужные пути до баз и просто переименовать буквы дисков.
С кластерами всё работает точно так же, просто процесс установки дольше, т.к. установить SQL и обновления нужно на все ноды
Вот такой простой подход позволил восстановить все серверы БД SQL Server без потерь в данных.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста, или зарегистрируйтесь, если не зарегистрированы.
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
Цирк с конями короче.
yaplakal.com