А теперь послушайте страшную историю о том, что вы действительно должны были сделать, дорогие мои 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 проходит по нескольким направлениям:
Механизм, использующий уязвимость SMBv1 (EternalBlue/EternalRomance) на находящихся в одной подсети с зараженным ПК компьютерах, Или механизм pass-the-hash/pass-the-ticket, используя имеющиеся на зараженном ПК сеансы пользователей.
Первый вариант распространения вируса на соседние ПК блокируется очень просто с 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.
UPD 1: По просьбам комментаторов и просто друзей в Facebook и прочих социальных сетях – записал практическое видео с примером реальной лабы по заражению домена Petya.C с правильно настроенными политиками безопасности согласно требованиям Defense-in-Depth для защиты от современных типов угроз (типа того же Pass-the-Hash/Pass-tht-Ticket, которые использовал Petya.C) – при явном заражении одного ПК – влияние вируса на остальную лабу – нулевое:
СофТы: закрываем уязвимости ИТ-инфраструктуры от современных атак (типа Petya – pth/ptt)
Да, тут некоторые коллеги в комментах дискутировали насчет того, что «нельзя так просто взять и поделить сеть на подсети пользователей и банкоматов – есть моменты администрирования и удобства работы» – но, в любом случае, у CIO было еще минимуму 3-5 дней на подумать, а потом решить, что удобство работы перед угрозой полномасштабной вирусной атаки – отходит на второй план. В общем – даже не думали и не сделали НИЧЕГО.
Наши потери от Petya после принятых общих мер – мы потеряли, скорее всего, все машины, которые заразились путем приезда «обновления от MEDoc» (хотя, при использовании IDS типа Defender ATP – и эти потери могут быть сведены к минимуму), мы потеряли 10% от тех машин, которые получили «письма счастья», а компания – потеряла работавших на них сотрудников. ВСЕ! Никакой эпидемии, никаких отключившихся касс и банкоматов (!!!), никаких тысяч часов на восстановление ИТ-инфраструктуры. Осталось восстановить требуемые данные из бекапов (или вообще ничего не восстанавливать, кроме ОС на ПК – если ИТ-инфраструктура сделана правильно и все хранится и бекапится централизованно, к тому же – в облако).
Так что это было, добродии?! Почему Petya гулял по украинским сетям, вынося всех и вся (и не надо рассказывать, что «в Европе/России тоже пострадали», «это была спланированная атака на Украину») – как не лень, некомпетентность и пофигизм CIO попавших под раздачу организаций и полный пофигизм Microsoft Ukraine по отношению к наземной угрозе?!
Ах да, Microsoft и «облака наше все»… Сейчас пойдут разговоры о том, что если бы «все было в Azure», то ничего бы не было. Было бы – с тем же результатом – ваши виртуальные машины в Azure были бы в той же ситуации – локальная сеть, открытые порты и т.п. – потому что в гибридной инфраструктуре облачная часть IaaS по безопасности ну никак не отличается от наземной по необходимости настроек.
Таким же образом, через обновления, Petya успешно бы пролез и на виртуалки в Azure, дальше бы пошел гулять по виртуальным сетям Azure (которые вы бы не поделили на сегменты, не изолировали, не использовали firewall на каждой), а потом и через Site-to-Site VPN залез бы и на наземные ПК пользователей… Или наоборот – с тем же результатом в такой незащищенной от угрозы изнутри “обланой” инфраструктуре.
А то было бы и хуже – учитывая умение Petya считывать учетные записи админов и зная безалаберность этих админов – Petya.Cloud (с модулем работы в облаке – дописать в код пару строчек) давно бы уже имел административные права на ваши подписки в облаках и делал бы там все, что заблагорассудится, кидая вас еще и на деньги – например – поднимал бы виртуалки для майнинга или ботсетей в вашей облачной подписке, за которые вы бы потом платили по 100К-300К уе/мес.
И даже использование облачного Microsoft Office 365, который вроде как SaaS и его инфраструктура защищается Microsoft – при такой дырявой инфраструктуре на местах – не спасет – с тем же успехом вирус добирается до админского аккаунта O365, используя воровство учетных записей – и дальше подписка O365 уже «не ваша».
Вам об этом не сказали Microsoft, Google, Amazon – все, кто продает «облака»? Так это, им же продать надо, а не решать ваши проблемы – а все проблемы облаков – находятся «на местах», а туда особо уже и не продашь – значит, и инвестировать в наземные части заказчиков не стоит ни копейки – даже тренингами и семинарами…
И всем – приготовиться – это была только следующая волна, ждем следующей, как только ребята найдут следующий механизм “заброски” и инфильтрации вируса в корпоративные сети. И этот вирус также не будет обнаруживаться антивирусами по сигнатурам и будет эксплуатировать свежие уязвимости сетей и незакрытые механизмы типа Pass-the-hash/Pass-the-ticket. И вот просто “перенести все в облака” вам не поможет, а подписка на облачные Microsoft ATA/Defender ATP в дополнение к описаным выше мерам – вполне.
И небольшой ликбез для тех, кому интересно (некоторые доклады – почти годичной давности):
О безопасности гибридной/облачной ИТ-инфраструктуры в Azure IaaS
И немного ссылок на другие материалы для тех, кто хочет стать просто ИТ-специалистом – смотрите первые шаги по созданию тестового рабочего места:
Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда
И еще – немного ссылок про ИТ-карьеру и тренинги/обучающие материалы для ИТ-профессионалов и Системных Администраторов:
Также, по просьбам посетителей – меня найти можно (добавляйтесь в друзья и подписчики):
-
мой канал на YouTube – www.youtube.com/iwalker2000 ;
-
в Facebook – http://www.facebook.com/igor.shastitko ;
-
в VK – http://vk.com/id194611286 ;
-
в Twitter – http://twitter.com/iwalker2000 ;
-
в Linkedin – https://www.linkedin.com/in/iwalker2000 ;
-
подробно обо мне здесь, на моем персональном техническом блоге – https://iwalker2000.wordpress.com/about/ .
Эмиграция для ИТ-профессионалов в Европу! Оформление ВНЖ в Словакии, возможность работы со всеми странами ЕС, открытие фирм, ЧП с соответствующими видами деятельности, оформление документов для членов семьи. Быстро, качественно, дешево и абсолютно легально ВНЖ в Словакии. www.slovakiago.com |
Игорь, привет.
Посещал Techdays и сидел в первых рядах.
Спасибо!
Моя инфраструктура устояла. 🙂
ПодобаєтьсяПодобається
[…] Вирус Petya и правильная комплексная защита от него и под… […]
ПодобаєтьсяПодобається
Игорь, спасибо за пост. Полностью согласен. Инфраструктуру нужно планировать. Изначально. Под все сервисы, которые будут эксплуатироваться. Я не слышал, чтобы были зам.директора ИТ по архитектуре инфраструктуры или по информационной безопасности. Менталитет? Авось? О гигиене рук или почистить утром и вечером зубы никто не забывает. Это вбили в советских детсадах и школе. А вот оставить трудовое место в чистоте… Или прочесть гайд 😛 Пожалуй, не все и не везде любят. И х-о-т-я-т! А правильная организация мыслей и обычная интуиция для многих просто недоступна 🙂 Удивило во всем этом бардаке то, что Майкрософт в официальном блоге ссылается на украинскую киберполицию… Это даже не смешно… А о том, что будут еще атаки – зачем об этом думать? 😀 Ведь мы героизмом по устранению инцидента покроем свою халатность 😀 Везет дуракам и дорогам – и те и другие существуют в своей выдуманной реальности
ПодобаєтьсяПодобається
http://ic.pics.livejournal.com/bga68/68022014/931475/931475_original.jpg / http://bga68.livejournal.com/251468.html
ПодобаєтьсяПодобається
Игорь, как перепостить пост в LiveJournal? Где кнопочки? 🙂
ПодобаєтьсяПодобається
А тем временем: “Держспецзв’язку попереджає про ймовірність повторної кібератаки” (www.pravda.com.ua/news/2017/07/6/7148924/) и дает новые рекомендации…
плакать хочется…
ПодобаєтьсяПодобається
Доброе время суток, Игорь.
Я не раз сталкивался с ситуацией, что пользователи подключают сетевые папки с документами как локальные диски: это удобно для работы и обмена данными и не надо запоминать путь к папке/ресурсу на системе хранения.
Естественно, вирус “нахозяйничал” и там, но данные были спасены благодаря наличию теневого копирования и бекапов.
Есть ли у МС рекомендации по защите подобных ресурсов? Я пошерстил течнет, но ничего годного не нашел. Хотя, по логике, защиту целостности данных должна обеспечивать система хранения данных.
ПодобаєтьсяПодобається
[…] Вирус Petya и правильная комплексная защита от него и под… […]
ПодобаєтьсяПодобається
[…] Вирус Petya и правильная комплексная защита от него и под… […]
ПодобаєтьсяПодобається
[…] Вирус Petya и правильная комплексная защита от него и под… […]
ПодобаєтьсяПодобається