![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bga68comp%20(168x180).jpg?zoom=2)
Вирус Petya и правильная комплексная защита от него и подобных следующих вирусов, которая должна была быть в каждой ИТ-инфраструктуре–то, что не сделали вовремя украинские CIO
А теперь послушайте страшную историю о том, что вы действительно должны были сделать, дорогие мои CIO – так сказать, «техническое алаверды» тому потоку негатива от обиженных CIO и “патриотов”, который последовал за публикацией предыдущего поста «про Petya» в ФБ – Трагедия и фарс–украинские CIO и 150 долларовые админы, российский след и “атака ФСБ”, тотальный факап Microsoft Ukraine–все, что вам надо знать о причинах вчерашней вирусной атаки в Украине…
Особенно «возбудились» почему-то некоторые «патриотические» деятели с дежурной фразой – «ты не живешь в Украине, какое право ты имеешь об этом писать!» – спасибо, повеселили, значит, мой «толстый» троллинг зацепил за живое…
Ладно, оставим лирику – все равно я всякое разное в ФБ комментах покилял, а самых ярых – заблокировал.
А мы посмотрим пошагово, чего же такого «провтыкали» CIO, что могло бы предотвратить эпидемию в украинских компаниях «на корню», что есть в базовых рекомендациях Defense-in-Depth https://msdn.microsoft.com/en-us/library/cc767969.aspx и реализовать которые не является большой проблемой. Напомню, требования Defense-in-Depth (DiD) достаточно простые и предусматривают реализацию тех или иных сервисов защиты на всех уровнях ИТ-инфраструктуры.
Уровень |
Технологии |
Данных |
ACL/шифрование/классификация данных с RMS |
Приложений |
SDL, антивирусы, «бронирование» приложений и сервисов, App/Device Guard |
Хостов |
«Бронирование» ОС, аутентификация, управление обновлениями, FW, защита от вторжения (IDS), VBS, Device Guard |
LAN |
Сегментирование и изоляция (VLAN), шифрование (IPSec), защита от вторжения (NIDS) |
Периметр |
FW, контроль доступа, App FW, NAP |
Физическая безопасность |
Охрана, ограничение доступа, аппаратный контроль и аудит доступа, отслеживание устройств, камеры наблюдения |
Люди, политики, процедуры |
Документирование, тренинги, предупреждения и уведомления, наказания… |
Есть и более «продвинутые» методы защиты, которые обеспечивают высокий уровень защиты от современных типов атак, которые в том числе, использовались и в Petya – Securing Privileged Access – http://aka.ms/privsec
Итак, начнем с первичного заражения. В данной эпидемии рассматривается 2 основных сценария – проникновение через почтовые сообщения в виде вложения к письму и через систему обновлений MEDoc, так называемую атаку «software supply chain attacks», когда взламывается поставщик ПО. Подробно, кто еще не прочитал – «разбор полетов» можете посмотреть здесь – https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
При этом в первом сценарии запущенный пользователем из почты исполнимый файл атакует ОС через уязвимости SMBv1 (EternalBlue/EternalRomance) и получает все требуемые права, чтобы выполнить свои процессы – шифрование и распространение.
Какие методы противодействия Defense-in-Depth помогут от подобной атаки:
- Периметр – сервис фильтрации почтовых сообщений (например, в Microsoft Exchange) – просто удаляющий все файлы, кроме разрешенных типов, антивирусная система для электронной почты, если нет чего-то подобного – аренда аналогичных облачных сервисов, например – Exchange Online Protection, «знания» которого не зависят от «расторопности» админов (время внедрения – 30 мин + обновление доменного имени).
- Приложения – антивирусы, которые ловили Petya.A с самого начала эпидемии. Надо обновлять сигнатуры – нет, не слышали?
- Хост – бронирование ОС – накатить готовые политики с рекомендованными настройками безопасности от Microsoft Security Compliance Manager или доточить их под рекомендации – например, отключить SMB v1 как класс и прочие ненужные устаревшие сервисы – плевое дело, управление обновлениями (совсем не сложно, особенно, если Windows не пиратская), с IDS сложнее, но даже тут – всего лишь подписка на Defender Advanced Thread Protection, который, как показала практика, ловит атаки подобного типа на корню.
- ЛПП – обучение не открывать файлы, предупреждение об возможных атаках и наказание – вплоть до увольнения и судебных исков против запустивших вирус (ах, да – страна такая, законы не работают – тогда просто переломайте запустившему вирус ноги).
Так что в данном случае – сам факт заражения существенно снижается…
Сценарий второй – вирус «прилетел» через обновление той или иной LoB-системы и здесь пока почти без шансов – скорее всего компьютер будет заражен, поскольку код выполняется от прав системы.
Но не будем расстраиваться. Мы потеряли один компьютер и далее все зависит исключительно от устойчивости ИТ-инфраструктуры в целом.
Дальнейший сценарий распространения вируса Petya проходит по нескольким направлениям:
Первый вариант распространения вируса на соседние ПК блокируется очень просто с Defense-in-Depth:
- LAN – сегментирование и изоляция (VLAN) – совсем просто, особенно учитывая кол-во накупленных в компаниях Cisco и прочего оборудования, надо только сесть и чуть подумать, какой же трафик куда должен ходить между сегментам пользовательских ПК (многочисленных и разнесенных тоже) и серверами приложений (тоже сегментированных между собой по типам приложений и требуемого сетевого доступа). Мы не говорим даже об NDIS – даже без обнаружения вторжения (хотя если Cisco – так чего бы не активировать?) – сегменты сетей стали бы непреодолимым барьером для проникновения вируса вне группы ПК.
- Хост – с его firewall, который, как ни странно, сейчас включается в Windows по умолчанию и только дурацкий ответ на вопрос – «хотите ли вы расшарить свои файлы в сети» – «да, хочу!» – портит всю картину. Ну вот зачем, зачем пользовательскому ПК вообще что-то публиковать в сети? Зачем все админы так любят отключать firewall? Легче работать? А не легче ли написать правила в групповых политиках… И все, даже в рамках одного сегмента сети – такие ПК c firewall будут защищены от посягательств зараженного ПК. А что насчет контроллеров домена и прочих файловых помоек – читай выше, обязательных обновлений и «бронирования» и тут никто не отменял.
- ЛПП – и да, не забываем о персональной ответственности админов и сетевиков за каждый следующий поломаный по сети комп.
Второй вариант распространения вируса чуть сложнее – Petya использует для атаки на другие ПК в сети наличие открытых пользовательских сеансов/кэшей паролей на зараженном ПК, а учитывая парадигму того, что многие админы на ПК используют один и тот же пароль локального администратора или учетную запись администратора домена для работы на любом ПК компании – здесь для Petya широкое поле деятельности с использованием механизмов атак pth/ptt. Имея на руках администраторские пароли и открытые «всем ветрам» порты соседних ПК – Petya успешно копирует себя через административные шары (Admin$) и запускает удаленно свой код на атакуемой машине.
НО, если обратиться к Defense-in-Depth, то можно обнаружить, что:
- Хост – рекомендовано использование технологий VBS и Device Guard для защиты от кражи идентити подобными способами. Но – VBS есть только в Windows 10 – Ok, но никто не мешает познакомиться с рекомендациями по защите хостов от Pass-the-hash/pass-the-ticket атак для Windows 7 и т.д. – ничего сложного, кроме опять же – использования рекомендованных шаблонов безопасности (их же можно использовать и для Windows 10 без VBS/DG) – http://aka.ms/pth – начиная с отключения кеширования идентити при входе и т.п.
- Хост – простейшая гигиена аутентификации, связанная с использованием уникальных администраторских паролей на каждой рабочей станции/сервере – утилита Local Administrator Password Solution (LAPS) – http://aka.ms/laps – избавит от головной боли «по запоминанию» каждого пароля, а далее – более сложные процедуры гигиены для администраторов, которые говорят, что для выполнения определенных действий на ПК должны быть использованы определенные учетные записи, не обладающие полнотой прав на уровне всей сети – https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material (а что, никто не в курсе, что с доменным админом ходить по рабочим станциям категорически запрещено?).
- Плюс – уже упомянутые выше механизмы обнаружения вторжения – тот же Defender ATP или Microsoft ATA («заточенный» как раз на обнаружение атак pth/ptt) и, безусловно – firewall и сегментирование сетей для того, чтобы завладевший теми или иными учетными записями вирус не смог подключиться к соседям.
- ЛПП – а здесь уже может “прилететь” и админу компании в целом, если окажется, что его учетная запись “гуляет” почему-то по рабочим местам пользователей или используется на ПК совместно с такими гуляющими админами.
ВСЕ! Было «охренеть как сложно», мы потратили от силы 3 рабочих дня (24 часов и 24х75=1800евро денег высококвалифицированного специалиста) из предоставленных 43 дней с предыдущей атаки для того, чтобы защититься от разрушительного действия вируса типа Petya.
Далее продолжение ->
